The Invoice Arrives, and So Does the Argument

The project is technically complete. The developer says so. The invoice says so. But you open the app, click around, and something feels wrong. The search feature works — but it is painfully slow. The contact form submits — but the confirmation email never arrives. The dashboard exists — but the numbers do not match what your spreadsheet says they should.

You are not imagining things. The build might genuinely meet every requirement that was written down. The problem is what was never written down at all.

This is the final-invoice fight, and it happens on projects of every size, in every industry. It is not caused by bad developers or unreasonable founders. It is caused by a gap between two honest definitions of the word done — a gap that could have been closed before a single line of code was written, if someone had insisted on writing real acceptance criteria.

Why 'Done' Means Something Different to Each Side

A developer, by training and instinct, thinks in terms of functionality. Does the feature work? Does it accept the right inputs and produce the right outputs? Does the code compile, deploy, and not crash? If yes, the ticket is done.

A non-technical founder or business owner thinks in terms of experience and outcome. Does the feature feel right? Does it solve the problem I hired someone to solve? Will my customers actually use this without calling me to complain? If not, it is not done — regardless of what the ticket says.

Neither perspective is wrong. But when these two definitions of done are never reconciled in writing, the project drifts toward a collision that no amount of goodwill can prevent. The developer feels the scope is being expanded after the fact. The founder feels they are being asked to pay for something half-finished. Trust erodes. The relationship sours.

Acceptance criteria exist to bridge exactly this gap. They are the single most important piece of documentation on any software project — and they are the piece most often skipped, rushed, or treated as someone else's responsibility.

What Acceptance Criteria Actually Are (and Are Not)

Acceptance criteria are specific, testable conditions that a feature or deliverable must satisfy before it can be considered complete. They are not vague descriptions of what the software should do. They are not a restatement of the feature request. They are the measurable finish line.

A weak example

The user should be able to search for products.

This tells the developer almost nothing about what you will actually accept. How fast should search results appear? Should it handle typos? Should it filter by category? What happens when there are zero results?

A grounded example

• Given a catalog of 10,000+ products, search results appear within 2 seconds.
• Search matches against product name, description, and SKU.
• If no results are found, the interface displays a message with suggested alternative terms.
• Search input is sanitized — special characters do not cause errors or blank screens.
• Results are paginated at 25 items per page with working next/previous navigation.

Notice the difference. The second version is specific enough that both you and your developer can independently look at the finished feature and agree — yes, this passes, or no, it does not. There is no ambiguity to argue about. That is the entire point.

The Five Elements Every Acceptance Criterion Needs

Not every criterion needs to be a novel. But each one should contain enough information to be testable without a follow-up conversation. Here is a grounded framework:

1. A clear actor

Who is performing the action? A logged-in user? An admin? An unauthenticated visitor? The system itself on a scheduled job? If you do not specify, the developer will assume — and assumptions are where scope disputes are born.

2. A specific trigger

What action or event initiates the behavior? Clicking a button, submitting a form, reaching a date threshold, an API receiving a payload. Name the trigger precisely.

3. An observable outcome

What should happen that a human can see, measure, or verify? Not what the code should do internally — what the user or stakeholder should experience. A page loads. An email arrives. A record appears in the database. A notification fires.

4. A boundary condition

What happens at the edges? When the input is empty. When the file is too large. When the user has no permission. When the network is slow. Edge cases are where most final-invoice fights actually live, because they are the conditions no one thought to discuss.

5. A performance or quality threshold

Speed, accuracy, uptime, accessibility — if it matters to you, it belongs in the criteria. A feature that works but takes 12 seconds to load is not done if your users will abandon the page after 3. Write the number down.

When to Write Them (Hint: Before the Contract)

Most projects go wrong not during development, but during the handshake. The proposal gets signed, the deposit gets paid, and the detailed acceptance criteria get deferred to sometime during the build. By then, momentum has taken over. The developer is coding. The founder is waiting. And the conversation about what done actually means keeps getting pushed to next week — until it becomes the conversation about the final invoice.

The right time to write acceptance criteria is during discovery and architecture — the soil work that happens before a single feature is built. This is where goals, constraints, and expectations are mapped with enough specificity that the build phase can proceed with shared understanding instead of parallel assumptions.

If your development partner does not have a structured discovery process — if they jump straight from a proposal to a sprint board — that is a signal worth paying attention to. The most expensive line item on any project is the one you pay twice: once to build the wrong thing, and again to rebuild it.

A Software Project Sign-Off Checklist You Can Use Today

Before you sign off on any milestone, deliverable, or final invoice, walk through these questions:

1. Do written acceptance criteria exist for every feature in this milestone? If the answer is no, stop. You are signing off against a feeling, not a standard.
2. Has each criterion been tested by someone other than the person who built it? The developer checking their own work is necessary but not sufficient. You, or someone on your team, need to verify the outcomes match the written criteria.
3. Have edge cases been documented and addressed? Empty inputs, large files, slow connections, missing permissions, duplicate submissions. If these are not in the criteria, they are not in scope — and they will become your problem after launch.
4. Are performance thresholds met under realistic conditions? A feature that works with 10 test records may collapse under 10,000 real ones. Test with production-scale data whenever possible.
5. Is the definition of done written in language both sides understand? If the criteria are full of technical jargon that only the developer can parse, they are not serving their purpose. Acceptance criteria should be readable by the person writing the check.
6. Have any changes to scope been documented with updated criteria? Scope changes happen on every project. That is normal. What is not normal — or healthy — is changing scope verbally and then arguing about what was agreed to. Every change gets written down, with updated criteria, or it did not happen.

The Trade-Offs Worth Naming

Writing thorough acceptance criteria takes time. It slows down the start of a project. It forces uncomfortable conversations about budget, priorities, and what is truly essential versus what would be nice to have. Some founders resist this because it feels like bureaucracy. Some developers resist it because it feels like micromanagement.

Both concerns are understandable. And both are outweighed by the alternative: a project that ends in dispute, a relationship that ends in resentment, and a product that needs to be reworked by someone new.

The investment in acceptance criteria is not overhead. It is foundation. It is the difference between a structure that holds weight and one that looks fine until the first real load lands on it.

There is a reason the best engagements start underground — with mapping, alignment, and documentation that feels almost tedious in the moment. That tedium is what makes the build phase feel seamless instead of chaotic. The fruit of a well-run project is rooted in the specificity of what was agreed to before the first commit.

What to Do If You Have Already Started Without Criteria

If you are mid-project and realizing that acceptance criteria were never properly defined, it is not too late — but it does require honesty from both sides.

Pause the build. Schedule a working session with your developer. Go feature by feature through what has been built and what remains. For each item, write the acceptance criteria together, right now. Document what has already been delivered and whether it meets the newly written criteria. If there are gaps, negotiate how to address them — as a scope adjustment, not as a blame exercise.

This conversation is harder than having it at the start. But it is infinitely easier than having it over a disputed invoice with a lawyer in the room.

Designing the Engagement You Actually Want

If you are a non-technical founder working with a development agency for the first time — or the third time after previous experiences that did not go well — the pattern to look for is this: does the team treat discovery as a real phase with real deliverables, or do they treat it as a sales call that ends with a proposal?

A grounded discovery process produces artifacts you can hold: documented goals, architectural decisions, user flows, and — critically — acceptance criteria for the first phase of work. These artifacts are not just process for the sake of process. They are your protection. They are the shared language that keeps two honest parties aligned through the inevitable ambiguity of building something new.

At Figtree Development, every engagement starts with this kind of foundational work. Before anything is built, designed, or automated, we map what done actually means — in terms both sides can read, test, and agree on. That is not a formality. It is the root system that lets everything above ground thrive.

Plant Something With Shared Ground

If you are heading into a software project — or stuck in the middle of one where done has become a moving target — the most valuable next step is a conversation that gets specific. Not a pitch. Not a proposal. A structured conversation about what you are building, what done looks like, and how to document it so both sides can move forward with clarity.

Book a free 20-minute discovery call with us at Figtree Development. We will help you define the criteria that matter before the build begins — so the finish line is something you and your development partner can both see.