Building an AI MVP: what founders should scope first

Most of my work for founders starts at zero: an idea, a deck, maybe a Figma file, and a deadline. Over 50+ shipped products I have learned that scoping decides more of an MVP's fate than the code does. Building an AI MVP adds a twist. The demo is easy. A model can produce something impressive in an afternoon. The hard part is making it work reliably on real inputs at a cost that survives real usage.

Here is what I ask founders to scope before any code gets written.

1. One job, done well

The strongest AI MVPs do one narrow thing that users currently do by hand. "An AI assistant for property managers" is a category. "Draft a reply to a tenant maintenance request from the request text and the lease" is a job.

A narrow job gives you:

• A clear input and a clear output.
• A way to tell whether the output is good.
• A user who can compare it against how they do it today.

Write it as one sentence: given X, the product produces Y for Z. If that sentence needs an "and", you are probably scoping two products.

2. Is there a non-AI version of this?

Ask honestly whether a form, a rules engine, or a search box would solve 80% of the problem. Sometimes it would, and that is a cheaper, faster, more predictable MVP. AI earns its place when the input is messy and unstructured (free text, images, voice, documents) and the output needs judgement a rule cannot encode.

Often the right answer is both: deterministic code for the parts with clear rules, and a model only for the step that needs it. I wrote about that split in AI agent or deterministic workflow.

3. Your data, checked early

AI products live or die on the data going in. Before building, find out:

• What inputs will users actually provide? Get ten real examples from the people who will use it: messy, incomplete, in the wrong format.
• Does the model need your private data to answer well? Product catalogues, past tickets, internal docs. If yes, you need retrieval, and the quality of that data matters more than the model.
• Can the data leave your infrastructure? Health, finance, and some enterprise clients have rules about where data is processed. This can rule out options early.
• Who owns it? Scraped or licensed data has terms. Check them before you depend on them.

Ten real inputs will tell you more about feasibility than any amount of discussion.

4. Define "good" before you build

This is the step founders skip most, and it is the one that causes the most pain later. An AI feature without a quality definition can only be judged by vibes, and vibes shift every time someone tries a new input.

Before the build:

• Collect 20 to 50 real inputs with what a good output looks like for each.
• Decide what counts as a failure: wrong facts, missing fields, wrong tone, unsafe content.
• Decide what happens when the model fails. Does the user see an error, a fallback, or a draft they can edit?

That last decision shapes the whole product. Many successful AI MVPs present output as an editable draft with a human in the loop, which makes imperfect output useful. See human-in-the-loop AI design for patterns.

5. Cost per user, roughly

You do not need precise numbers, but you need an order of magnitude. Estimate:

• How many model calls a typical user triggers per session.
• How large each call is (input plus output).
• How many sessions per user per month.

Multiply by your provider's current price and compare it to what you plan to charge. If a free user costs you real money every day, solve that pricing problem before launch. Caching, smaller models for simple steps, and limits on free tiers are the usual levers.

6. What to leave out of v1

To ship in weeks instead of months, cut:

• Fine-tuning. Start with prompting and retrieval. Fine-tune later if evaluations show a gap prompting cannot close.
• Autonomous agents. A fixed pipeline of one or two model calls is easier to debug and cheaper to run. Add autonomy when you know which decisions the model should own.
• Multi-model routing. Pick one model that clears your quality bar. Optimise later with real usage data.
• Custom infrastructure. Use the model API directly behind one small internal wrapper so you can swap providers later.

7. What to keep in v1

Some things are cheap early and expensive to add later:

• Logging every model call with inputs, outputs, latency and token counts, with care around personal data. You will need it the first week users report something strange.
• Output validation. If code consumes the output, validate it against a schema.
• A feedback button. Thumbs up or down on outputs gives you a growing evaluation set for free.
• Rate limits. One abusive user should not be able to run up your bill.

How I'd scope a first build

When a founder brings me an AI idea, the first deliverable is usually a short spec: the one job, ten real inputs with expected outputs, the failure behaviour, a rough cost per user, and the list of what is deliberately out of v1. I write that before the code, following the same Spec-Driven Development approach I use with my team. Building from that spec is fast. Building without it is how MVPs turn into six-month rewrites.

The short version

Scope one narrow job, test it on ten real inputs, define what good output looks like, and estimate cost per user before you build. Leave fine-tuning and agents for later, and keep logging, validation and feedback from day one. If you are planning an AI product and want a second pair of eyes on the scope, here is how I work with founders.