The Argument You Can Prevent in Advance

Near the end of a development project, two people look at the same prototype and reach opposite conclusions. The firm sees a device that does everything the statement of work described. The client sees something not ready to sell. Both are honest. The problem is that "done" was never written down as a testable condition.

Acceptance testing is the mechanism that removes the ambiguity. It is a defined set of checks, agreed before development starts, that either pass or fail. Handover is what physically and legally transfers when they pass. Get both into the contract at kickoff and the end of the project becomes an event on a calendar rather than a negotiation.

What Makes an Acceptance Criterion Usable

A usable criterion is measurable, has a stated method, and has a pass threshold. Compare:

  • Bad: "The device should have good battery life." Good: "With the default profile and a 2,000 mAh cell at 77 F (25 C), the device runs 14 hours minimum, measured on three units, from full charge to low-battery cutoff."
  • Bad: "The enclosure should be water resistant." Good: "Passes IPX4 per IEC 60529 at an accredited lab, three units, no ingress and full function after test."
  • Bad: "The app should be responsive." Good: "Pairing completes in under 8 seconds from app launch on the three named reference phones, 9 out of 10 attempts."
  • Bad: "The product should be robust." Good: "Survives 26 drops from 4 ft (1.2 m) onto concrete per the agreed drop matrix with no functional loss and no crack propagating through a wall."

Each criterion needs a sample size, an environment, and a named test method. This is the same discipline as formal design verification, and the distinction that matters most is the one explained in verification vs validation: verification proves the product meets the spec, validation proves the spec was the right one. Acceptance testing is verification. If the spec was wrong, passing acceptance will not save you, which is why the criteria should be derived directly from a product requirements document written at the start.

Three Levels of Handover

Not every project ends at the same place, and the price difference between these levels is large. Decide which one you bought.

Level 1: working prototype. The firm demonstrates the concept functioning in a controlled setting. Deliverable is one to three units plus source files. This proves the idea; it proves nothing about manufacturability, cost, or reliability. Appropriate for a proof of concept or an investor demo, and the cheapest place to stop.

Level 2: verified design. The design has been tested against the full requirement set, results are documented, and the design is frozen at a revision. You get a release package. This is the normal end point of a development contract.

Level 3: production-ready release. Adds a closed-out DFM review, released tooling data, a quoted supplier, pilot units on production-intent processes, and defined test fixtures. It lets you place a production order without further engineering and typically adds 20 to 35 percent to project cost.

Most disputes are Level 2 contracts with Level 3 expectations. Write the level into the agreement in plain words.

What Physically Changes Hands

The deliverable list should be an appendix to the contract, not an email at the end. At minimum:

  • Native CAD files in the original format, not only STEP exports, plus 2D drawings with tolerances and datums.
  • Electronics package: schematics, PCB layout in source format, Gerbers, pick-and-place, and a costed BOM with approved manufacturer part numbers and second sources.
  • Firmware and software source code in a repository you control, with build instructions that a new engineer can follow, and any toolchain versions or license keys required.
  • Test reports for every acceptance criterion, with raw data, not just a summary table.
  • Assembly documentation: exploded views, torque specs, fixture drawings, and the end-of-line test procedure.
  • The prototypes themselves, labeled by revision, including the failed units, because failed hardware is diagnostic evidence.
  • The open-issues list, signed by both parties.

Together these are the manufacturing data package. If any element is missing, you are not free to move the project to another firm or factory, and everyone in the room knows it.

The Open-Issues List

No project ends with zero known problems, and pretending otherwise turns handover into a fight. Maintain one written list from mid-project onward with four columns: the issue, its severity, the owner, and the decision. Severity should be blunt: blocking, must fix before production, fix in a later revision, or accepted as-is.

Reviewing that list together is the actual handover meeting. Items marked "accepted as-is" become documented decisions rather than surprises found three months later. This list is also the input to the first engineering change orders after release, and it is the single most useful artifact if you ever need to switch engineering firms.

Tying Payment to Acceptance

A final payment of 10 to 20 percent held until acceptance passes is standard and reasonable. Two conditions make it fair to both sides. First, the acceptance criteria must be fixed at contract signature, not written at the end, or the client can withhold payment indefinitely by raising the bar. Second, there must be a time limit: the client has 15 or 30 business days from delivery to run acceptance and issue a written pass or a specific list of failures, after which acceptance is deemed granted.

Define the retest loop too. A typical structure gives the firm two correction rounds included, with further rounds billed. Without that, a single disputed criterion can consume months. These clauses belong in the same section as scope and change pricing, alongside the rest of your product development contract terms, and their shape depends on whether the engagement is fixed price or time and materials.

After the Signature

Handover is not the end of the relationship. Budget a support period, typically 30 to 90 days, during which the firm answers questions from your factory at no charge, and agree an hourly rate for support beyond that. Record a knowledge-transfer session, especially for firmware, and confirm that repository access, cloud accounts, certificates, and vendor logins move into your organization's name rather than an engineer's.

Then plan the next phase deliberately. A verified design still has to survive a real production run, and the gap between a passed acceptance test and a stable line is exactly what a pilot production run exists to expose.

Set Acceptance Criteria Before You Sign

Projects House writes acceptance criteria into the statement of work at kickoff, runs the tests against them, and hands over a complete package you can take to any factory. If you are mid-project and "done" was never defined, we can help you write the criteria retroactively. Reach us through our contact form.