Acceptance criteria
The checks that decide whether a piece of work is done, agreed before the work starts so nobody argues about it afterwards.
Updated October 2026 · with examples from our own builds
What does acceptance criteria mean in practice?
Acceptance criteria turn 'it works' into something testable. For each feature they say what a user can do, what the system must refuse and what has to be true in the data afterwards. Good ones are specific enough to become automated tests: given this input, expect that result.
They protect both sides of a contract. You get a clear point at which to sign off and release a milestone payment; the team gets a definition of finished that doesn't move. Without them, the final stretch of a feature tends to expand to fill whatever budget is left.
Be wary of criteria that only describe the happy path. The ones that earn their keep describe failure: a payment that arrives twice, a user without permission, a server that restarts halfway through a job.
Acceptance criteria at a glance
- Written by
- The founder and the lead engineer together
- When
- Before the work is estimated, not after it is built
- Good sign
- Each criterion can be turned into a test
Where has acceptance criteria come up in our builds?
Before switching payments on, we audited the whole payment path and logged 35 findings. By 16 July 2026, 33 were closed, each with its own acceptance test and commit, before the renewal engine was built on top of it.
The admin backend's exit-criteria document records more than 376 unit tests and 14 integration tests. Its deploy-time checks, such as probing the database role and live 2FA enrolment for every staff account, are marked as not yet run because there is no staging or production deployment.
Common questions about acceptance criteria
Who should write the acceptance criteria for my app?
Draft them together. The founder knows what a user must be able to do and what the business can't allow; the engineer knows the failure cases, such as duplicate payments or a restart mid-job, that each need their own line.
What if a feature passes its criteria but still feels wrong?
Treat it as a gap in the criteria rather than a failed build. Add the missing case, agree whether it belongs to the original scope or is a change request, and keep the new criterion so the same gap can't reopen.
Related terms
Planning a product and not sure where acceptance criteria fits? Ask us, or browse all 116 terms in the glossary.