The AI MVP is the most over-scoped artifact in software right now. Founders ask for a copilot. Three weeks in, the scope has grown a roadmap, a billing system, an admin panel, and a Slack integration. The thing that was supposed to validate one assumption is now validating thirty, badly. Two-week MVPs that ship and teach beat ten-week MVPs that stall every time. The format itself has a name we use across engagements: a discovery sprint.
The MVP paradox.
The minimum viable product is supposed to be the smallest artifact that proves a single business hypothesis. In practice, most teams build the smallest version of an entire product, which is a different and much larger thing. The first is a probe. The second is a prototype that costs as much as v1. Confusing the two is the most expensive mistake in early-stage AI work.
"An MVP is one assumption, dressed for testing. Not a product, dressed for an investor."
Rule 1, scope the MVP to one decision.
Every AI MVP should answer one decision the operator currently makes by hand. Not three. Not the full workflow. One. “Can this draft the first version of an outbound email better than a blank canvas?” “Can this triage support tickets into three buckets correctly enough?” “Can this score inbound leads against a written rubric?” If the answer is no, you have learned something cheap. If yes, the second decision is a separate MVP, run later.
Rule 2, ship one surface.
The fastest MVP we ship is a single page with a single input field and a single output panel. No login, no settings, no history, no admin. The operator pastes one example, the system returns one answer, the operator scores it. Repeat for forty examples. That is the entire product for the duration of the MVP. Adding any second surface, an admin panel, a settings screen, an account, doubles the timeline and halves the learning.
Rule 3, agree on one fact you'll accept.
Before the MVP starts, the operator and the studio agree on the single number that will count as a pass. “If the system gets the triage right 80% of the time on a 50-example fixture set, we will fund the build.” The number is written down. Either it clears the bar or it doesn't. The MVP is over when one fact has been accepted, not when the calendar runs out.
The MVP that has no exit criterion will run until the founder loses interest. Write the exit criterion on day one.
Anatomy of a real two-week MVP.
Our Labs & Prototyping engagements follow the same skeleton:
- Day 1, framing. One workshop, three hours, write down the one decision and the one fact to accept.
- Days 2 to 3, fixtures. Curate 30 to 60 real examples from the operator's actual work, labeled with what a good output looks like.
- Days 4 to 6, build. One model, one prompt, one retrieval source. The simplest possible architecture that could pass the bar.
- Days 7 to 10, eval. Run the fixture set, score against the rubric, iterate. The bulk of the timeline lives here, not in the build.
- Days 11 to 12, surface. A single-page interface, plain, functional, no chrome. The point is the operator pressing the button.
- Days 13 to 14, decide. Run live with the operator. The number is the number. Pass or no-pass. No middle.
When not to build an MVP at all.
Sometimes the right move is to do the work by hand for a month and skip the MVP entirely. If the decision in question happens fewer than 50 times a month, build a spreadsheet and an SOP. AI MVPs are for decisions that recur often enough to make the eval loop worth assembling. If the answer is “this happens twice a quarter,” you don't have an AI problem yet.
Common questions.
How long should an AI MVP take to build?
Two weeks of focused effort, end to end, including framing, fixtures, build, eval, and the first operator test. Anything longer is a v1 in disguise.
What goes in an AI MVP and what gets cut?
In: one decision, one surface, a fixture set, an eval rubric, a pass/no-pass number. Out: authentication, settings, admin panels, integrations, billing, multi-user. All of those belong in the post-MVP build, not the MVP.
What if the MVP fails the eval bar?
You learn something for the price of two weeks instead of two quarters. The MVP cost is the price of the lesson, and the lesson reshapes the next bet. We run the same shape for investor-ready proof builds and for internal feasibility tests; the structure is identical.
If you have a decision that recurs often enough to deserve a probe, we scope MVPs in a single call and start the next Monday.
Run this with us.
