The risky assumption is different
In a conventional MVP the question is whether anyone wants it. In an AI MVP there is usually a second, sharper question: will it be accurate enough on our actual data to be useful?
That question can be answered far more cheaply than a product, and it should be answered first.
Answer accuracy before building anything
- Take fifty real cases with known correct answers
- Run the intended approach against them
- Measure per field or per category, not overall
- Show the results to whoever will use it and ask whether that is good enough
This costs days rather than weeks. If accuracy on fifty real cases is poor, no amount of engineering rescues the use case — the problem is the problem, not the implementation.
What the MVP must include
- The core workflow end to end, actually working
- An evaluation set that runs on every change
- A review interface, because the first version will need humans
- Instrumentation showing completion and correction rates
- A way for users to report that something is wrong
What can wait
- An admin panel — a developer running a query is adequate for the first fifty users
- Multiple roles — permissions multiply testing faster than anything else
- Self-service billing — invoice the first customers manually; it is better research
- Additional document types or languages — prove one first
- Automatic actions — start with suggestions a human approves
Manual behind the curtain is legitimate
If the hard part is a process, run it by hand at first. The customer sees a form and receives a result; behind it a person does the work with AI assistance.
It is the cheapest possible test of whether the result is worth paying for, and it produces exactly the labelled data you need to automate later.