Acceptance Criteria In Writing: What Makes Fixed-Scope Software Projects Safe
"Fixed scope" sounds safe. A defined deliverable, a defined price, a defined date. But scope described only in prose ("a working dashboard", "an AI assistant for support") is not fixed at all. Both sides imagine something different, and the gap between those two pictures surfaces at the worst possible moment: delivery.
What actually fixes a scope is a short list of acceptance criteria: written, testable statements that define what "done" means before work starts.
What A Good Criterion Looks Like
A useful acceptance criterion is something a non-engineer can verify by looking at the running system. Compare:
Vague: "The system classifies incoming support emails."
Testable: "Given the 50 sample emails provided by the client, the system assigns a category and a suggested response to at least 45, and every classification is visible in the review queue with a confidence score."
The second version does three jobs at once. It tells the engineer exactly what to build, it tells you exactly what to check at the demo, and it turns the final acceptance conversation from an opinion exchange into a checklist.
The Small Set That Prevents Most Disputes
You do not need dozens of criteria. For a 2 to 6 week build, a one-page list usually covers it:
1. Functional criteria. Three to eight statements like the example above, each tied to sample data or a concrete scenario agreed in advance.
2. Exclusions. What the project deliberately does not include. Exclusions are not pessimism; they are the honest edge of the budget. Every dispute I have seen started in the unwritten space.
3. Quality gates. Where the system must run (your cloud account), what it ships with (documentation, a runnable setup, handover notes), and what happens to the code (your repository, assigned in writing).
4. A demo cadence. Weekly demos of working software, with your sign-off recorded. Criteria checked weekly cannot drift far.
Change Is Fine. Silent Change Is Not.
Fixed scope does not mean frozen scope. Real projects learn things. The protection is a formal change process: when new information changes the plan, the criteria list is updated in writing, with the impact on time and price stated before the work happens. What must never happen is silent scope creep in either direction: the vendor quietly cutting corners, or the client quietly adding "one small thing" per week.
Who Should Write The First Draft
The vendor should. Writing testable criteria requires knowing what is technically verifiable, and a vendor who resists putting criteria in writing is telling you something important about how delivery will go. Your job is to review the draft and make sure it describes your business problem, not just convenient technical outputs.
At Urbano DX, acceptance criteria and exclusions are fixed in the statement of work before any build starts, demos run weekly against them, and a milestone that fails its criteria gets fixed before it counts as delivered. That last sentence is the whole safety mechanism: criteria only protect you if failing them has a consequence.
If you want to see what a criteria-first scope looks like for your project, the paid audit produces exactly that document.