Before asking AI to build an app, write five answers and one acceptance check

A five-line brief gives an AI-assisted prototype a concrete starting point: one user, one trigger and an output you can inspect.

Consider a fictional product idea called LessonWrap, intended to help independent tutors write a weekly lesson report. Start by deciding what one completed workflow would look like.

Replace it with five concrete answers:

• User: an independent tutor who already has lesson notes.
• Trigger: writing the weekly report after the final Friday lesson.
• Current workaround: copy notes into a document and manually check unfinished follow-ups.
• Observable output: an editable report and a visible list of items still to do.
• First-version boundary: no real student accounts, billing or automatic messages.

This brief creates a useful next question: what would count as the prototype working?

Use synthetic records to define the first checks. Empty input should produce a clear message. A malformed record should identify the field that needs correcting. A valid fictional lesson should produce a report that can still be edited. A download should preserve the words the user entered, including symbols and non-English text. The tool should explain what happens to edits when the page closes.

Write each check as an input and a result you can inspect. This gives you a way to judge the next implementation pass.

Try this prompt with your own brief:

Convert this brief into six acceptance checks. For each check, provide a synthetic input, an observable expected result, and the boundary of what the check proves. Keep unknowns as unknowns. Do not invent user validation, performance figures or integrations.

Brief: [paste your five answers here]

The next pass should look for missing decisions. Does the prototype send data to a server? Can a user inspect the generated output before it leaves the page? Are the examples fictional? Does export create a backup that import can actually restore? These questions matter more than adding another screen to the demo.

A compact acceptance record could look like this:

{
  "case": "backup_round_trip",
  "input": "a fictional lesson report with an edited follow-up",
  "action": "export a backup, clear the form, import that backup",
  "expected": "the edited follow-up returns unchanged",
  "proves": "the backup preserves the tested fields",
  "does_not_prove": "real classroom adoption or production security"
}

Once you have a small working slice, record what you checked and what remains untested. Then use feedback to change the brief. You do not need to manufacture a market survey to justify the next prototype.

I prepared AI MVP Blueprint as a downloadable workbench for this process. It includes six editable worksheets, twelve prompts, English and Chinese guides, CSV files and the clearly fictional LessonWrap example. The desktop browser tool works offline and creates text and JSON exports. A visible download link lets you save the file after inspecting its content. Session edits need an explicit backup before closing.

The planning exercise above is free to use. The ready-made workbook is a paid product at $9: https://nickster2735.gumroad.com/l/ai-mvp-blueprint

It is a planning toolkit, with no AI account, API credits, hosting or custom development included. The text and toolkit were prepared with AI assistance, and the examples are fictional.