MVP Acceptance Criteria: How to Define Done Before You Pay

Acceptance criteria are the short, testable sentences that say exactly when each MVP feature is finished, and you should have them written and agreed before you pay anyone. A feature with criteria is done when every sentence passes on a preview link; a feature without criteria is done when the developer says so, and that gap is where most MVP disputes live. For a typical five-feature MVP in 2026 that means 20 to 30 sentences and about two hours of founder time. This guide shows the sentence formula, gives you ready-to-copy criteria for login, payments and dashboards, and explains why this is the cheapest insurance you can buy before a $4,000 to $15,000 build.

Why "done" has to be written down before the build

Most founders hand a vendor a feature list that reads like this: user login, Stripe payments, admin dashboard. All three are real features, and all three are completely untestable as written. "User login" can mean an email and password form with no password reset, or Google and Apple sign-in with two-factor codes and session expiry. The first is a day of work. The second is a week. If the price was agreed against the two-word version, both you and the vendor will believe you were right when the preview arrives.

That ambiguity has a price. In our experience the MVP projects that go wrong rarely have a bad developer; they have a feature list that left 30 to 50 percent of the behavior undefined, which both sides then filled in differently. Each round of "that is not what I meant" costs 2 to 5 working days, billed at $60 to $150 an hour on an hourly contract. Three rounds on a six-week project means launching in week nine instead of week six, plus $2,000 to $6,000 you did not budget.

Acceptance criteria close that gap in advance. They are the plain-English contract of what the product does, written in sentences anyone can check. If you are still deciding what goes in the build at all, read how to prioritize MVP features first; criteria are for the features that survived that cut.

The formula: one testable sentence per behavior

A good acceptance criterion has three parts: a specific action, an observable result, and a limit. If any of the three is missing, the sentence cannot be checked and will not protect you. The simplest template that works for non-technical founders is:

Compare the two versions of the same requirement:

• Untestable: "Users can reset their password easily."
• Testable: "When a user clicks Forgot password and enters a registered email, then a reset link arrives at that address within 60 seconds, and the link stops working after 30 minutes or after one use."

The second version can be checked by you, on a preview link, in under two minutes, without reading a line of code. That is the test for every criterion: could a careful friend with no technical background perform it and answer yes or no? If the answer is "it depends," rewrite it.

Three words that make a criterion useless

• "Easily," "intuitive," "user-friendly." Nobody can pass or fail these. Replace with a click count or a time: "in three clicks or fewer from the home screen."
• "Fast," "quickly," "responsive." Replace with seconds: "the dashboard loads within 3 seconds on a normal mobile connection."
• "Works," "handles," "supports." Replace with the specific input and the specific output: "accepts a CSV up to 5 MB and shows a row count when the upload finishes."

The failure case is half the criterion

Founders write the happy path and forget the ways it can go wrong, and that forgotten half is where surprise revisions come from. For each feature, add at least one sentence that begins "When the user does the wrong thing" and says what the product shows: wrong password, declined card, empty form, file too large. The expected behavior is usually a clear message and no data loss, and writing it down takes 30 seconds.

Sample acceptance criteria for the three most common features

These three features appear in almost every MVP and generate the most "I assumed" conversations. Copy them, change the numbers to fit your product, and delete what you do not need. The prices reference what each MVP feature costs in 2026, because the scope you write here is what sets that number.

Login and accounts (typically $800 to $2,500 of a build)

• When a new visitor enters an email and a password of at least 8 characters and clicks Sign up, then an account is created and the user lands on the dashboard within 3 seconds.
• When a visitor signs up with an email that already has an account, then the form shows "An account with this email already exists" and no second account is created.
• When a user enters a wrong password, then the form shows a clear error, the password field clears, and after 5 wrong attempts in 10 minutes the account is locked for 15 minutes.
• When a user clicks Forgot password and enters a registered email, then a reset link arrives within 60 seconds and stops working after 30 minutes or one use.
• When a user closes the browser and returns within 7 days, then they are still signed in; after 30 days of no activity they are asked to sign in again.
• When a user clicks Sign in with Google, then they are signed in or registered without a password form, and their name and email are filled in from Google.

Notice the last sentence is optional. If you leave it out, your vendor should not build Google sign-in, and you should not expect it in the preview. That is the discipline: the list is the product.

Payments (typically $1,000 to $3,000 of a build)

• When a signed-in user clicks Upgrade and completes the Stripe checkout with a valid card, then their account shows the paid plan within 10 seconds and a receipt email arrives within 2 minutes.
• When a card is declined, then the user sees the decline message from Stripe, stays on the checkout page, and their account stays on the free plan.
• When a paid user clicks Cancel subscription, then the account stays paid until the end of the current period, shows the end date, and drops to the free plan on that date without a manual step.
• When a monthly renewal fails, then the user receives an email within 1 hour and gets a 7-day grace period before paid features are switched off.
• When an admin opens the payments list, then every charge, refund and failed payment appears with the user's email, the amount and the date, and matches the Stripe dashboard.
• When a test is run with Stripe's test card numbers on the preview link, then every sentence above passes without touching a real card.

The last criterion makes the vendor prove the payment flow on the preview link with test cards, so you are not clicking Pay with your own card the night before launch. For the full payment design, see how to add payments to your MVP.

Dashboards and admin (typically $1,500 to $4,000 of a build)

• When a signed-in user opens the dashboard, then it shows their last 30 days of activity as a list and one chart, and loads within 3 seconds with 1,000 records.
• When the user has no data yet, then the dashboard shows a short message and one button that starts the first action, instead of an empty chart.
• When the user picks a date range, then the list and the chart update to that range within 2 seconds and the range stays selected after a page refresh.
• When the user clicks Export, then a CSV with the visible columns downloads within 5 seconds for up to 10,000 rows.
• When an admin opens the admin panel, then they can search users by email, see each user's plan and sign-up date, and deactivate an account with one confirmation step.
• When a non-admin user types the admin panel address directly, then they see a "not allowed" page and no admin data.

What a complete set looks like: a worked example

Here is a realistic five-feature MVP for a small bookings product, with the criteria count and the rough share of a $9,000 build per feature. The point is the right-hand column: a feature with zero criteria is a feature you cannot accept or reject.

Twenty-seven sentences took this founder about two hours to draft and 40 minutes on a kickoff call to finalize. Every item in the last column would otherwise have surfaced in week three as "I assumed that was included." The same list becomes your demo checklist later; how to review a weekly MVP demo explains how to use it that way.

Acceptance criteria vs the spec vs the contract

These three documents do different jobs, and you want all three, but they are not the same size.

Attach the criteria to the contract as the definition of delivery. A contract that says "deliver the MVP as described in the proposal" leaves "as described" open to argument. For the larger document, how to write an MVP spec covers the structure, and the criteria slot in under each feature.

Why this stops endless revisions

Revision loops happen when "done" is a feeling rather than a list. The founder looks at the preview, something feels off, the developer changes it, and the loop runs until someone runs out of patience or money. On an hourly contract you pay for that loop. On a fixed-price contract the vendor pays, which is why good fixed-price studios insist on criteria even when the founder does not ask.

With criteria, the preview either passes sentence 14 or it does not. If it does not, it is a defect and the vendor fixes it inside the agreed price. If it passes but you now want something different, that is a change, and you decide whether to swap it for something you are cutting or pay for it. What disappears is the third path: the argument about whether the thing in front of you is what was ordered.

Three effects we see when a project starts with written criteria:

• Review time drops. Checking 27 sentences against a preview takes 30 to 45 minutes. Reviewing a preview with no list takes an afternoon and produces vague feedback.
• Scope creep becomes visible. Every "can we also" is a new sentence, and a new sentence has a cost. Founders add less when the adding is explicit.
• The guarantee becomes checkable. A promise like "live in 14 days" only means something if both sides agree what live means. What a 14 days or you don't pay guarantee really covers walks through that definition; criteria are the mechanism behind it.

How to write yours in two hours

1. List your features, 3 to 5 of them. If you have more than seven, you are not writing criteria yet; you are still scoping. Cut first.
2. For each feature, write the happy path as 2 to 4 sentences using the When / then / within formula. Use real numbers even if you are guessing; a wrong number is easy to correct and a missing number is not.
3. Add at least one failure sentence per feature. Wrong input, declined payment, empty state, no permission.
4. Read every sentence aloud and ask "could my friend test this?" Rewrite any sentence with "easily," "fast," "works" or "properly."
5. Send the list to the vendor before the kickoff call. Ask them to mark each sentence as in scope, out of scope, or needs discussion. The marked-up list is your agenda; how to prepare for an MVP kickoff call has the rest of that checklist.
6. Freeze the list in writing the day the price is agreed. Changes after that date are edits with a visible trade, never verbal.

For a number against the list before the call, run the same features through the free MVP cost calculator. At SquadPrime the criteria are agreed before the build starts and the price is fixed against them: one price from $4,000, typically $4,000 to $15,000 depending on scope, built by senior professionals, with a private preview link you can click by day 5 and a live demo every few days. If it does not work by day 14, your invoice is zero and we keep building until it ships, and 100 percent of the code is yours on delivery.

FAQ

What are acceptance criteria for an MVP?

Acceptance criteria are short, testable sentences that define when a feature is finished. Each one describes a specific action, the expected result, and a limit such as time or count, so that anyone can perform the step and answer yes or no. A feature is done when every one of its criteria passes on the preview link.

How many acceptance criteria should each MVP feature have?

Three to six per feature is the working range. Fewer than three usually means the failure cases are missing, more than eight usually means the feature is really two features and should be split. A typical five-feature MVP ends up with 20 to 30 criteria in total, which takes a founder about two hours to write.

Do I need a developer to write acceptance criteria?

No. Acceptance criteria describe what a user does and sees, not how the code works, so a non-technical founder is the right person to write them. Write the first draft yourself, then let the build team add the edge cases they know from experience. The founder owns the intent and the team owns the mechanics.

What happens if a feature fails its acceptance criteria?

The feature is not done and the fix is part of the agreed price. That is the whole point of writing criteria before the build starts. On a fixed-price project the vendor keeps working until the criteria pass; on an hourly project you would be paying for the fix, so written criteria matter even more there.

Can acceptance criteria change during the build?

Yes, but only in writing and with a visible trade. If you discover a criterion was wrong after the kickoff, edit it and agree whether the change is free, swapped for something you are cutting, or added to the price. Silent changes, verbal changes and changes made in a chat message are what create disputes.

All third-party names and trademarks belong to their respective owners and are used for identification only. Any market figures reflect our experience building MVPs and typical ranges as of October 10, 2026, and may change at any time. Spotted something outdated or inaccurate? Email talk@squadprime.com and we'll correct it promptly.

Related: How to Write an MVP Spec (Free Template and Examples) · How to Review a Weekly MVP Demo Without a Technical Background