“Looks right” is a reasonable thing to say about a first draft. It is a dangerous thing to base a final payment on, because it depends entirely on who is looking, on what day, and how carefully.

The final third of a build’s payment is due only when written acceptance criteria — agreed at the Diagnostic stage, before any building starts — are actually met. Not when the delivery date arrives, and not when someone’s general impression is that the result looks fine.

01. What “looks right” actually leaves unresolved

Two reviewers can look at the same delivered system and disagree, honestly, about whether it does what was promised — not because either is being difficult, but because “what was promised” was never written down precisely enough to check against. That ambiguity is where disputes come from, and it is avoidable.

02. What we do instead

Acceptance criteria are drafted and agreed in writing during the Workflow Diagnostic — before design, before build, before a single line of the system exists. They describe, specifically, what the finished system has to do for the workflow it was built around. The full delivery sequence, stage by stage, is on How It Works; the criteria are set at stage one and tested against at stage three.

During build and testing, the system is checked against each criterion individually — not against a general sense that it works. At handover, formal acceptance happens against those same written criteria, and only then does the final payment fall due.

03. Why this protects both sides, not just the client

It is easy to read “we don’t get paid until acceptance criteria are met” as purely a client protection. It also protects us: without written criteria, “finished” is a matter of opinion that can keep moving. Written criteria mean the build has a defined, achievable endpoint — not an open-ended obligation to keep adjusting until someone’s mood changes.

It is also why the payment structure is staged the way it is: 40% on commencement, 30% at the agreed build milestone, and 30% only on acceptance against the criteria set at the Diagnostic. Overruns caused by our own estimation are absorbed by us — the direct consequence of measuring properly before quoting, as covered in why we don’t quote without a Diagnostic.

04. What happens when scope changes mid-build

Scope changes are normal in real projects. What is not normal, in our process, is a scope change reaching your invoice without having gone through written change control first — agreed, priced and scheduled before anyone does the work. Nothing lands on a bill that was not agreed to in advance.

05. The document you actually get

At handover you receive three things together: the handed-over system tested against every criterion, the documentation, and a written exit path. Acceptance is not a verbal sign-off in a meeting — it is a specific, recorded event tied to a specific version of the system, which is also what makes the audit trail meaningful later.

See the full eight-stage delivery method, including exactly where acceptance criteria are set and tested — how it works →