Acceptance criteria: how a non-technical founder defines done

Acceptance criteria, rewritten for the person paying for the software instead of the person building it. A plain-language way to define “done” for every feature you commission, agreed before the work starts, so delivery day is an inspection and not an argument.

A founder I worked with last year ran a boutique bookkeeping firm. She was paying a studio to build a client portal, and the spec said, in full: “Clients can upload their monthly receipts.” Everyone nodded. Three weeks later the feature was “done.” Clients could upload a file. One file. No way to tell which month it belonged to, no confirmation it had arrived, no limit on size, and a PDF over ten megabytes failed silently. She thought she had bought a receipts inbox. She had bought a file picker. Nobody had lied to her. The sentence she approved was simply not a definition of done.

Acceptance criteria are the conditions a piece of software has to meet before you agree it is finished and correct. They turn a vague feature request into a short list of things that are either true or false on delivery day. In agile teams they are usually written by product managers in a rigid syntax. For a non-technical founder buying a custom build, that framing is the wrong one. You are not writing tickets for a team you manage. You are defining what you are paying for, to people you do not manage, so that “done” means the same thing to them as it does to you.

Why “done” is the most expensive word in your build

The gap that hurt my bookkeeping founder is the gap between what a feature sounds like in a meeting and what it has to actually do for a real person. “Clients can upload their monthly receipts” is a wish. It feels complete because you can picture it. But a developer cannot build a picture. They build the literal instruction, and where the instruction stops, they make a reasonable guess. Their reasonable guess is shaped by what is fastest to ship, because they have a deadline too. Your reasonable guess is shaped by what your customer needs. Those two guesses are almost never the same, and the difference surfaces at the worst possible moment: when the work is “delivered” and the money is due.

This is the delivery-day argument every non-technical founder eventually has. You say “this isn’t what I meant.” The studio says “this is what was written.” You are both right, and now you are negotiating a rebuild with no leverage, because the thing you are pointing at was never written down in a form anyone could check. Acceptance criteria are how you avoid that conversation. They move the disagreement to the start, when it costs an email instead of a milestone.

What acceptance criteria are not

They are not the requirements document. The requirements doc says what to build and why. Acceptance criteria say how you will know each piece is built correctly. The first is the order; the second is the receipt you check it against.

They are not user acceptance testing either, though the two get confused constantly. Acceptance criteria are written before the build, as a definition. User acceptance testing is the process at the end where you sit down and verify the criteria were met. You write the criteria once; you run the test against them later. Without the criteria, the test is just you clicking around hoping to notice what is wrong, which is how founders sign off on software that breaks the first week a real customer touches it.

And they are not a substitute for deciding what to build at all. If you have not done the work of feature prioritization, writing acceptance criteria for forty features just produces forty well-specified things you cannot afford. Criteria come after you have decided a feature is worth building, not instead of that decision.

The four questions that turn a wish into a criterion

You do not need Gherkin, “Given-When-Then,” or any of the formal syntax the agile blogs will hand you. That syntax exists to help engineers automate tests, and you are not automating tests. You need criteria you can read and check yourself. Here is the test I give every non-technical founder before they approve a feature. Run each proposed criterion through four questions.

One: is it about a person doing something, not a quality the software has? “The portal is user-friendly” is not checkable. “A client can upload a receipt and find it again next month” is. Write criteria as actions a real user takes, with a result they can see. Qualities like fast, clean, and intuitive are opinions; actions are facts.

Two: can you check it yourself, without the developer in the room? If verifying a criterion requires the person who built it to explain why it counts as done, it is not a criterion. It is their opinion wearing a criterion’s clothes. The whole point is that you can sit down alone and rule pass or fail. If you can’t, rewrite it until you can.

Three: is it binary? A criterion has exactly two outcomes: it passed or it didn’t. “Looks good” has infinite outcomes and is therefore worthless on delivery day. “An uploaded receipt shows the month it was filed under, and a file over ten megabytes shows an error instead of failing silently” either happens or it doesn’t. The moment a criterion needs a judgment call, split it into the specific things you were actually judging.

Four: was it settled before the build? A criterion invented at delivery is a renegotiation, not a standard. The leverage in acceptance criteria comes entirely from agreeing them up front and attaching them to what you are paying for. A criterion you add after the work is done is a favor you are asking, and you will pay for it like one.

The rule of thumb underneath all four: a good acceptance criterion is one you could hand to a stranger, and they could tell you pass or fail without asking you a single question. If a stranger would need to ask “what does done mean here,” so will your developer, and they will answer it for you in whatever way ships fastest.

What acceptance criteria look like in practice

Take the receipts feature that started this. “Clients can upload their monthly receipts” is the wish. Run it through the four questions and it becomes a short, checkable list:

• A logged-in client can upload a PDF or image receipt and tag it to a specific month.
• After upload, the client sees the receipt in a list for that month, with the filename and date.
• A file larger than ten megabytes is rejected with a visible message, not a silent failure.
• The client can delete a receipt they uploaded by mistake, and it disappears from the list.
• The firm’s staff can see every client’s receipts for a given month in one view.

None of those sentences mentions code. Every one of them is something the founder can sit down and check in five minutes, alone, on delivery day. That is the entire test. Notice the list also did something quieter: it surfaced decisions nobody had made yet. Should staff see receipts in one view? Can clients delete? Those questions are far cheaper to answer now, in writing, than after a developer has guessed at them.

Five plain sentences are not extra work. They are the work you were going to do anyway, moved to the only point in the project where it is still cheap.

Where acceptance criteria meet the money

This is the part the agile blogs never cover, because their readers are not the ones signing the invoice. For a founder, acceptance criteria are not a documentation nicety. They are the definition of when a payment is owed.

A well-structured software development contract ties milestone payments to acceptance, not to calendar dates. “Phase two is paid when the receipts module passes its acceptance criteria” is a clean, enforceable sentence. “Phase two is paid on June 30th” pays for time, whether or not the thing works. If your criteria are vague, your milestones are vague, and you are effectively paying for activity rather than outcomes. Tight criteria are what let you pay for outcomes without micromanaging the build, which is the entire reason a non-technical founder hires a partner instead of a team they have to stand over.

This is also why a capable studio will welcome your criteria rather than resist them. Vague acceptance is as dangerous for the builder as for you: they never know when they are finished, and “done” keeps moving. Clear criteria protect both sides. A partner who pushes back on writing down what “done” means is telling you something about how they intend to define it later.

Where founders get acceptance criteria wrong

The first mistake is writing too many. You do not need criteria for every conceivable behavior. You need them for the handful of things that, if they came out wrong, would make the feature useless or embarrassing. Five sharp criteria on the receipts module beat fifty that nobody will check. Acceptance criteria you do not verify are not criteria; they are decoration.

The second mistake is hiding requirements inside them. A criterion describes a condition the agreed feature must meet. It is not the place to smuggle in new functionality you forgot to ask for. If “clients get an email when their receipt is approved” was never in the build, it is a change, and it belongs in a conversation about scope, not in an acceptance checklist presented at delivery.

The third, and most common, is accepting “looks good” from yourself. The founder who skims a demo, sees the happy path work once, and signs off is the founder who discovers the ten-megabyte silent failure when a real client hits it. Acceptance is an inspection. Run every criterion, including the ugly ones about what happens when something goes wrong. The criteria about failure are usually the ones that separate software you can put in front of a paying customer from software that merely demos well.

Frequently asked questions

What is an example of acceptance criteria?

For a feature like “clients can upload receipts,” a useful acceptance criterion is: “A logged-in client can upload a PDF, tag it to a month, and see it in that month’s list afterward; a file over ten megabytes is rejected with a visible message.” It names a real user action and a result you can verify yourself, with two clear outcomes: it works or it doesn’t.

What are sample acceptance criteria for a non-technical founder?

Good samples are always plain sentences about a person doing something and seeing a result: a user can reset a forgotten password and log in with the new one; an admin can export this month’s orders to a spreadsheet; a customer who enters an invalid card sees an error and is not charged. Avoid samples written in code syntax. You need criteria you can read and check, not ones built for test automation.

What are the three C’s of acceptance criteria?

In agile practice the three C’s are Card, Conversation, and Confirmation: the feature on a card, the discussion about what it means, and the confirmation it works. For a founder buying a build, the useful translation is: write down the feature, talk through what “done” means before work starts, and confirm against that definition at delivery. The confirmation step is the one founders skip, and it is the one that costs them.

Who writes the acceptance criteria, the founder or the developer?

Draft them yourself, in your own words, because they encode what your customer needs and only you know that. Then hand them to your development partner and let them sharpen the technical edges and flag anything ambiguous. Criteria written only by the builder tend to describe what is easy to build; criteria written only by the founder tend to miss edge cases. The agreed version, settled before the build, is the one that protects you.

Acceptance criteria are the cheapest insurance in a custom build. A handful of plain sentences, agreed before anyone writes code, is what stands between you and the delivery-day argument where you have already paid and lost your leverage. Define “done” while it still costs an email. The studio that takes your criteria seriously is the one worth keeping.