A working demo is not a launch decision
A founder watches an AI feature turn one document into a useful answer. The demo is convincing. Then a customer uploads an incomplete file, the model times out, or a teammate sees information they should not see. None of those problems is resolved by making the prompt sound better.
AI MVP acceptance criteria turn “it works” into a shared, testable decision. Write them before the build starts so the team can price the work and the founder can approve a release with evidence.
This guide covers that approval decision. For the broader delivery plan, read how to launch an MVP in 12 weeks.
If buyer demand, data quality, or AI behavior is still uncertain, test that uncertainty with a bounded prototype before committing to a full build. Acceptance criteria can guide that experiment too. Passing them does not prove that customers want the product.
Start with one complete customer task
Use a sentence that names the user, input, result, and boundary. For example:
A service coordinator uploads a supported request document, receives a draft summary with source references, corrects it, and saves an approved version. The application does not send a quote or promise a service date.
This is a hypothetical product example, not a Somnio client result. Its value is the boundary: a reviewable draft is a smaller commitment than an autonomous customer-facing action.
Record what is outside the first release too. Additional file types, extra user roles, automatic sending, and new integrations are separate scope decisions. Keep a later-release list so useful ideas do not silently become launch requirements.
Make the criteria observable
Avoid “fast,” “accurate,” and “secure” without a test. Use a short acceptance sheet:
| Area | Example criterion | Evidence to collect |
|---|---|---|
| Core task | An authorized user can upload, review, correct, and save | Recorded end-to-end test |
| Source use | Each factual summary statement has a supporting source passage or is flagged for review | Reviewed output sample |
| Missing data | The system marks an absent service date as unknown | Incomplete-file test |
| Access | A user cannot read another customer’s documents | Cross-account access tests |
| Failure | A timeout preserves the upload and gives a safe retry path | Simulated provider failure |
| Cost | Usage per completed task stays within the agreed operating budget | Usage and billing evidence |
These are examples to adapt, not a complete specification. Choose response-time limits, file limits, and budget limits with the delivery team. Write down the test environment and expected load so a laptop demo does not stand in for a production test.
For a product meant to save work, measure the complete task, including checking and correcting the AI output. Compare it with the current method. Agree with intended users on what improvement would make the product useful.
Separate application tests from AI evaluation
The application should enforce permissions, save edits, and reject unsupported uploads consistently. Test these behaviors with ordinary software tests.
AI evaluation asks a different question: is the output useful enough for this task? Prepare a sample of normal inputs, difficult inputs, and inputs the product should refuse. Have someone who knows the work define the expected answer or grading rules. Include short documents, long documents, missing fields, conflicting statements, and requests outside the product’s purpose.
Keep some examples out of prompt tuning. If the team repeatedly adjusts the system against every available example, a strong score can reflect memorized test conditions rather than useful behavior on new work. Record the model, prompt, settings, and test set used for each evaluation so a later change can be compared fairly.
Name the buyer-side expert who will supply examples and judge results, and reserve time for that work in the delivery plan. Choose the sample size from task variety, volume, and the consequence of a missed error; a few successful demonstrations are not enough evidence for a high-consequence action.
Do not hide serious failures inside an average. A missed heading and a fabricated payment instruction have different consequences. Track error types separately and decide which ones block launch. If reviewers disagree about an answer, clarify the scoring rule before treating the result as evidence.
Agree on the failure path before the happy path is finished
Ask the team to demonstrate what happens when the model is unavailable, output is incomplete, a customer retries, or an integration accepts a request but its response is lost.
The user needs to know whether the work is pending, failed, or complete. A retry must not create a duplicate customer action. For higher-consequence outputs, keep a person in control until the business has enough evidence to approve a narrower automated action.
Define a release owner and a rollback decision. Who can pause the feature? Where will staff finish work manually? What happens to tasks already in progress? A short operating procedure is more useful than an assurance that someone will “monitor AI quality.”
Keep acceptance separate from new scope
During testing, classify each finding:
- Defect: the agreed behavior does not work as specified.
- Clarification: the requirement is ambiguous and needs a recorded decision.
- Change: the buyer wants behavior outside the agreed requirement.
Do not use this distinction to dismiss a real defect. Use it to prevent a new feature from being disguised as a bug, or a bug from becoming a surprise invoice. Record the evidence, owner, resolution, and retest result for each launch-blocking issue.
Agree who resolves disputed findings. Before signing, check what the contract requires when acceptance fails: correction, retesting, milestone approval, and any exit rights. Do not assume a post-delivery defect window defines the remedy for an unfinished build.
Somnio’s AI MVP service defines workflows, launch criteria, AI responsibilities, and exclusions before implementation. Its focused package starts at $20,000 when requirements fit, with a 12-week target dependent on scope, access, and timely feedback. Third-party model, hosting, and API fees are identified separately. This is a scoped service offer, not evidence that every AI idea can launch on that schedule.
The approval packet a founder should receive
Before approval, ask for the agreed acceptance sheet, test results, known limitations, operating-cost assumptions, deployment instructions, and a named support route. Record which unresolved issues are acceptable and why. Do not accept a serious failure simply because the calendar says launch day.
Use the custom software handoff checklist to verify that the receiving team can run the release and its documented checks.
Somnio’s published CRM automation case study gives an operational example of proving a change before cutover: imported orders were reconciled against existing spreadsheets during a parallel run. That was an existing workflow replacement, not an AI MVP validation study. The transferable lesson is to compare the new system against a known result before relying on it.
You can use this checklist without hiring anyone. Write one customer task, list its failure cases, and ask what evidence would make you comfortable releasing it. If those answers are still unclear, review the AI MVP package before committing to a build.
