How to Scope an AI MVP That Actually Ships

The failure mode for AI products is not that the model is not good enough. It is that six months went into building something broad and shallow, and the first real user contact happened after the money was mostly spent.

Scope is the whole game, and scoping an AI product has some specific traps that ordinary product scoping does not.

Cut to one user, one job, one path

The version that ships solves one problem, for one type of user, one way.

Not one problem with three input methods. Not one problem for two user types who mostly overlap. One path, end to end, deployed, with real data.

The instinct to resist is breadth-as-insurance: covering more cases because you are not sure which one matters. It feels like risk reduction and it is the opposite. Every additional case multiplies the surface you have to make reliable, and you learn less from a broad prototype than from a narrow thing that people actually use.

Identify the load-bearing screen

Every product has one screen where the real complexity lives. The review queue. The comparison view. The thing that shows the AI output alongside the evidence for it.

Build that first, before auth, before settings, before onboarding. It is where all the hard design questions are, and it is the screen that determines whether the product is any good. Everything else is a form.

Scope the AI part narrowly and specifically

This is where AI projects diverge from ordinary ones.

Name the exact task. Not “AI-powered analysis.” Rather: “given a document of this type, extract these eleven fields into this schema.” Vague AI scope produces unbounded AI work.

Define what wrong looks like, before you build. If you cannot articulate what a wrong output is, you cannot evaluate the system, and you will end up shipping on vibes.

Assume it will not be perfect and design the interface around that. The single biggest determinant of whether an AI feature works in practice is what the interface does with uncertainty. Show the evidence. Make correction cheap. Let the user override without friction. A system that is right seventy percent of the time with a two-second correction path beats one that is right ninety percent of the time with no way to intervene.

Pick the boring model first. Start with the cheapest model that plausibly works and measure it. Teams routinely start with the most capable model, build everything around its latency and cost, then discover the cheap one was fine.

What to leave out of version one

Onboarding flows. Set the first accounts up manually. You will learn more from watching someone use it with you than from any wizard.
Settings and configuration. Every option is a decision you have not made. Make it, hard-code it, revisit later.
Admin panels. Query the database. You are the admin.
Notifications. Almost never load-bearing in a first version, and always more work than expected.
Mobile, unless the job genuinely happens on a phone.
Integrations, beyond the one that is essential. Manual import is fine at ten users.
Fine-tuning. Prompt and context engineering gets you much further than teams expect, and it does not lock you to a model.

What must be in version one

Real authentication. Not a shared password. It leaks into the data model too deeply to retrofit comfortably.
The real data model. Interfaces are cheap to change; schemas are not. This deserves genuine thought up front.
Evaluation. For any AI component, from day one. You cannot bolt this on later, because you will have no baseline.
Logging of AI inputs and outputs. Every call, retained. It is your debugging record, your eval set, and your evidence when someone disputes an output.
A correction path. Wherever the AI produces something a user relies on, they need a way to fix it — and you need to capture the fix.

The timeline that is realistic

For a focused AI product with one path and one user type:

Week 1 — domain model, the hard screen as a clickable prototype, evaluation set assembled.
Weeks 2–3 — core path working end to end against real data, deployed.
Weeks 4–5 — the AI component measured, tuned against the eval set, guardrails in.
Week 6 — real users, real work, instrumentation on.

Six weeks to something genuinely usable. Anything materially longer usually means the scope was not cut hard enough, and the honest fix is to cut again rather than extend.

What comes after

The point of shipping narrow is that the roadmap stops being a guess. Six weeks of real usage tells you which of your assumed priorities were wrong — and in our experience roughly half of them are.

Build the next thing from what people actually did, not from the backlog you wrote before anyone had used it.

We scope and build AI products on this shape of timeline. See how we work, or read about evaluating the AI parts properly.