An AI MVP should use a hosted model through an API rather than training one, spend its budget on the workflow around the model, and measure accuracy on a hundred real examples before the feature is built into the product. The AI part of an MVP costs $5,000 to $25,000 (€4,500 to €22,000, £3,500 to £18,000) on top of the product around it and takes two to four weeks. You need no proprietary model, no data science team and no GPU budget to prove that users want the feature. You need those things only once they have.
Prices are in US dollars. Euro and pound figures in parentheses are approximate, rounded conversions. Quotes are issued in the currency of your contract.
Founders building an AI MVP tend to start in the wrong place: with the model. They look for a data scientist, worry about training data, and price GPU time. None of that is needed to find out whether users want the feature, which is the only thing an MVP is for. This post sets out how to build an AI MVP in the order that works: hosted model first, workflow second, product third, and a trained model of your own only if the evidence demands it.
Why should an MVP use a hosted model?
Hosted models from the major providers already read documents, classify text, extract fields, summarise, translate, describe images and hold conversations at a quality that took research teams years to reach. They are billed per use, available in an afternoon, and good enough for the first version of almost any AI feature. Training your own model is slower, costs more, and tells you nothing about demand that a hosted model would not. It becomes worth considering later, when the feature is proven and the per-use cost or the accuracy on your specific data justifies it. Our post on whether your app should use AI helps decide whether the feature belongs at all, and what adding AI costs has the pricing.
What are the steps?
- Pick one task. The one users or staff spend the most time on, where the input is unstructured. Reading invoices. Classifying tickets. Drafting replies. One, not a strategy.
- Collect a hundred real examples. Real inputs and what a good output looks like for each. This takes a few days and is the most valuable work in the whole build. If you cannot get a hundred examples, the task may not be as common as you think.
- Prototype in a week. A script that sends each example to a hosted model with a carefully written prompt and records the output. No interface, no product. Just the task.
- Measure. Compare the outputs with the good ones. Count how many are right, how many are close, and how many are wrong in a way that would matter. Write the percentage down.
- Decide the review step. If accuracy is 95 percent, a user can glance and confirm. If it is 70 percent, a person must check every output, and the feature is an assistant, not an automation. If it is 50 percent, the task is wrong for the current models and you have learned that for a few thousand dollars.
- Build it into the product. Only now. The feature, the review step, the fallback when the model fails, and the analytics that show whether users accept the output.
Where does the budget actually go?
| Part | Share of AI feature cost | What it is |
|---|---|---|
| Prompt design and evaluation | 20 percent | The prompt, the examples, the measurement harness |
| Workflow around the model | 50 percent | Getting the input in, showing the output, the review step, the fallback, the retries |
| Data handling | 15 percent | Minimising what is sent, privacy, provider agreements, logging |
| Monitoring | 15 percent | Acceptance rate, cost per use, failure alerts |
The model itself is close to zero percent of the build cost and a modest line in the running cost. The workflow is where AI features succeed or fail, and it is ordinary software engineering.
What does an AI MVP need that other MVPs do not?
- A review step designed first. Models are wrong some of the time. Where being wrong costs something, the person who checks is part of the product, and the interface for checking is a feature to design.
- A fallback. The provider will have outages and rate limits. The product must do something sensible when the model does not answer, even if that is a queue and an email.
- Acceptance tracking. Did the user keep the output, edit it, or discard it? That number is the retention metric for an AI feature, and it must be collected from the first day.
- A data answer. Sending user content to a third party is a processing activity under privacy law. Choose a provider with the right agreement, send the minimum, tell users, and write down where the data goes. What data you need before AI can help covers this from the business side.
- A cost ceiling. Per-use billing scales with users. Set a per-user cap and an alert before launch, not after the first invoice.
When would you train your own model?
When three things are true: the feature is proven and used, the hosted model's accuracy on your specific data is the limiting factor and you have thousands of examples to improve it, and the per-use cost at your volume is material. Even then, the first step is usually fine-tuning a hosted model on your examples rather than training from scratch. Most products never reach this point, and that is fine. A product with a hosted model and retention beats a product with a proprietary model and none.
The AI MVP in one week
- Day one: pick the task and collect real examples.
- Day two: write the prompt and the measurement script.
- Day three: run the hundred examples, read every output.
- Day four: adjust the prompt, run again, record accuracy.
- Day five: decide the review step and whether to build.
How 7L builds AI MVPs
We run the one-week evaluation before any AI feature is scoped into a build, and we show the founder the accuracy number and the wrong outputs before they commit. About a third of the time the honest result is that a rules engine does the job better, and we say so. The rest of the time the feature goes into the MVP with the review step, fallback and acceptance tracking as standard. Our guide to AI features that actually work in early-stage products lists the ones that pass most often. If you have a task and a hundred examples, send them over and we will run the evaluation.
Frequently asked questions
Do I need a data scientist to build an AI MVP?
No. An AI MVP built on a hosted model needs a good software engineer who can write and evaluate prompts, handle the workflow and measure results. A data scientist becomes useful later, when there is enough usage data to improve on the hosted model.
How much does the model cost to run?
It depends on volume and the task. Classifying a short message costs a fraction of a cent. Summarising a long document costs a few cents. For most early products the monthly bill is small compared with hosting and salaries, but it scales with users, so set a cap.
Is a chatbot a good AI MVP?
Rarely, unless conversation is the job. Most tasks are done faster with a button than with a chat. A chatbot as the interface to a product that did not need one is the commonest AI MVP mistake. Our post on chatbot or custom AI explains when each fits.
What accuracy is good enough?
It depends on the cost of a wrong answer. Above 95 percent with a quick human glance works for most tasks. Between 70 and 95 percent the feature is an assistant that drafts and a person confirms. Below 70 percent the task is not ready for automation with current models.
Can I switch model providers later?
Yes, if the integration is built behind a boundary from the start, which we do as standard. Prompts need adjusting between providers, but the workflow around the model stays the same. Avoid provider-specific features in the first version unless they are the point.