The Dispute That Was Already Baked In

A founder approves a proposal. A development team starts building. Six weeks later, the feature is delivered and the founder says, This is not what I asked for. The developer says, This is exactly what you described. Both are telling the truth.

This is the most common failure mode in software projects, and it has nothing to do with bad developers or unreasonable clients. It starts with a word everyone uses and nobody defines: done.

When done lives only in someone's head — or worse, when each side carries a different mental picture of it — the build is already drifting before the first commit. Acceptance criteria exist to make that invisible picture visible, shared, and testable. They are the single most effective tool for avoiding scope disputes with developers, and they cost almost nothing to create if you do the work before the build begins.

What Acceptance Criteria Actually Are (and Are Not)

Acceptance criteria are specific, observable conditions that a deliverable must satisfy before it can be considered complete. They are not vague aspirations. They are not feature lists. They are not the same thing as requirements, though the two are related.

Think of it this way: a requirement says what you want built. Acceptance criteria say how you will know it was built correctly.

A requirement might read: Users should be able to reset their password. That sounds clear until you start asking questions. Does the reset link expire? After how long? Does it work if the user has two-factor authentication enabled? What happens if they request three resets in five minutes? Does the confirmation page redirect to the dashboard or the login screen?

Each of those questions, answered concretely, becomes an acceptance criterion. And each one left unanswered becomes a place where the founder's mental picture and the developer's implementation quietly diverge.

The Pattern That Works

Good acceptance criteria follow a predictable structure. They describe a scenario, a condition, and an expected outcome. You do not need formal syntax to get value from them, but a consistent shape helps everyone — technical and non-technical — read them the same way.

A practical template:

• Given [a specific starting state],
• When [a specific action is taken],
• Then [a specific, observable result should occur].

For the password reset example: Given a user requests a password reset link, when more than 30 minutes pass without the link being used, then the link should expire and display a message prompting a new request.

That sentence is testable. A developer can build to it. A founder can verify it. A QA engineer can write an automated check against it. And if the behavior does not match, the conversation is grounded in a shared document, not competing memories of a call from six weeks ago.

Why Non-Technical Clients Especially Need This

If you are a business owner who does not write code, acceptance criteria are your best protection — not because developers are adversarial, but because translation loss is real. You describe what you want in business language. A developer interprets that through technical constraints you may not know exist. Without acceptance criteria, there is no checkpoint between your intent and their interpretation until the thing is built.

This is the exact gap that acceptance criteria for non-technical clients are designed to close. You do not need to understand the implementation. You need to describe the behavior you expect to see — what happens on the screen, what the user experiences, what changes in the data. If you can describe the outcome in plain language, you can write acceptance criteria. The format is less important than the specificity.

The Questions That Surface the Criteria

Most business owners already have strong intuitions about what done looks like. They just have not been asked the right questions. Here are the ones that reliably surface hidden assumptions:

• What does the user see when this works correctly? (Forces a visual, concrete answer.)
• What should happen when something goes wrong? (Error states are where most disputes hide.)
• Who should not be able to do this? (Permissions and access control are often assumed, not stated.)
• How fast does this need to respond? (A three-second page load and a 200-millisecond page load are different engineering problems.)
• What existing behavior should stay exactly the same? (Regression — breaking something that already works — is a silent scope issue.)

A good discovery process asks these questions systematically, before the architecture is designed and before the build begins. At Figtree, this is exactly what the Discovery and Architecture phase is for: mapping the terrain so the foundation is solid before anything goes up.

How to Define Project Success Metrics That Survive Contact With Reality

Acceptance criteria handle the micro level — individual features, screens, workflows. But projects also need a macro definition of done: what does success look like for the project as a whole?

This is where many engagements go wrong in a subtler way. The individual pieces may all pass their acceptance criteria, but the founder still feels dissatisfied because the aggregate result does not move the metric they actually cared about. The checkout flow works perfectly, but conversion did not improve because the real bottleneck was the product page — which was never in scope.

Defining project success metrics means naming, before work starts:

1. The primary business outcome this project should move. Not a feature. An outcome. Revenue, retention, time-to-deploy, error rate, customer support volume. Something measurable.
2. The baseline. Where is that metric today? You cannot measure improvement without a starting point.
3. The target. What would make this investment worthwhile? Be honest about what is realistic in the timeline.
4. What is out of scope. This is the most important one. Scope creep does not usually come from greed. It comes from silence about boundaries. Writing down what the project will not do is just as foundational as writing down what it will.

These four items, documented and agreed on, create what amounts to a project sign-off checklist at the strategic level. They give both sides a shared frame for evaluating whether the engagement delivered real fruit — not just completed tasks.

The Sign-Off Checklist: Making the Handoff Clean

A project sign-off checklist is the final layer of the definition of done for software projects. It is the document both sides walk through when the build is delivered, and it should contain no surprises — because every item on it was agreed to before development started.

A grounded sign-off checklist typically includes:

• Feature-level acceptance criteria status. Each criterion marked as pass, fail, or deferred (with a documented reason for deferral).
• Environment verification. The deliverable works in the environment it was built for — staging, production, the specific devices or browsers that were scoped.
• Data and integration checks. If the feature touches other systems, those connections are verified as integrated and functioning.
• Performance against stated thresholds. Load times, uptime targets, or throughput numbers that were defined during discovery.
• Documentation delivered. If operational documentation, runbooks, or training materials were part of the scope, they exist and are accurate.
• Known issues log. A transparent list of anything that did not make the cut, with context on severity and a recommendation for when to address it.

This is not bureaucracy. It is clarity. And clarity protects both sides. The developer gets a clean, defensible delivery. The client gets confidence that what they are accepting actually matches what they asked for.

Where This Goes Wrong (and the Trade-Offs Involved)

Writing acceptance criteria takes time. That is the honest trade-off. Discovery work — the soil work before the build — adds days or weeks to the front of a project. For a founder under pressure to ship, that delay can feel painful.

But the math is straightforward. A week of discovery and criteria writing prevents, on average, far more than a week of rework, re-scoping meetings, and dispute resolution later. The cost of ambiguity is always paid. The only question is whether you pay it in planning (cheap, calm, collaborative) or in production (expensive, stressful, adversarial).

The other common failure is writing criteria that are too vague to be useful. The page should load quickly is not a criterion. The page should load in under two seconds on a 4G mobile connection is. Specificity is what makes this tool work. If a criterion cannot be tested by someone who was not in the room when it was written, it is not specific enough.

A Note on Living Documents

Acceptance criteria are not a contract you chisel into stone. Good projects evolve. New information surfaces. User feedback shifts priorities. The criteria should be updated when scope genuinely changes — but the change should be explicit, documented, and agreed to by both sides. The document is not a cage. It is a shared map. When the terrain changes, you update the map together instead of each navigating by a different, outdated version.

Start With the Foundation

Every strong build starts underground. The features, the interface, the automation, the content — those are the visible structure. But the acceptance criteria, the success metrics, the shared definition of done — that is the root system. Without it, even good work grows in the wrong direction.

If you are about to start a build — or if you are mid-project and realizing the definition of done was never made explicit — the most valuable thing you can do right now is stop and define it. Not in a conversation that disappears into memory. In a document that both sides can point to.

At Figtree Development, this is where every engagement begins. Before a single line of code is written or a single workflow is automated, we sit down and map the terrain together: what does done look like, how will we measure it, and what is deliberately out of scope. That is the soil work. And it is what makes the difference between a project that delivers real fruit and one that just technically shipped.

If you want to start your next project on solid ground, book a free 20-minute discovery call with us. No pitch. Just a conversation about where you are, where you are trying to grow, and what the foundation needs to look like to get there.