What drives the cost of an MVP, and how to scope yours

The cost of an MVP is driven by scope, not by a price list: how many types of user it serves, how many systems it connects to, how money moves through it and how much is still unclear. AI-assisted development makes the routine parts faster, but decisions, data design and reliability still take real engineering time.

This article explains those cost drivers, what keeps a first version small, and how to scope yours so that any quote you receive, from us or from anyone else, covers what matters and leaves out what does not. It deliberately contains no price figures: without your scope, any number would be a guess.

What counts as an MVP?

An MVP (minimum viable product) is the smallest version of your product that a real customer would use and pay for. It does one core job well and includes the basics that let you run a business around it: accounts, payments, email and a way to see what users do. It is not a clickable prototype, and it is not a feature-complete platform.

That definition matters for cost. A prototype that only has to impress in a demo can be built in days. A product that stores real customer data, takes real payments and has to keep working while you sleep needs more care, and that care is most of the work.

What drives the cost of an MVP?

Cost follows complexity, and complexity comes from a handful of predictable places:

• More than one type of user. Every role, such as customer, provider, admin or team member, adds screens, permissions and edge cases.
• Integrations. Each external system, such as a CRM, an accounting tool or a booking calendar, adds work to connect, test and keep working when the other side changes.
• Money moving between people. Taking a subscription is simple. Splitting payments between a marketplace and its sellers, with refunds and payouts, is not.
• Data you cannot afford to lose. Orders, contracts and anything with legal weight need backups, audit trails and careful changes to the database.
• Compliance. Health, finance and children's data bring requirements that shape the whole build.
• Unclear scope. When the core user journey is still open, part of the budget goes into discovering it. That is normal, and it is why we quote unclear work in phases.

What keeps an MVP small?

The smallest MVP is the one with the fewest features that still proves the idea. In practice that means:

• One core journey. Pick the single thing a customer must be able to do, and build that well.
• Standard building blocks. Sign-in, payments, email and analytics should use proven services, not custom code.
• Manual work behind the scenes. If an admin can approve accounts by hand for your first customers, you do not need an approval workflow yet.
• No native apps in version one. A responsive web app reaches phones on day one. Native apps can follow once people use the product.

Do you need an MVP at all?

Sometimes the fastest way to test demand is not a product. If the idea is really one repetitive task done better, a single AI automation or a small internal tool can prove the value first, and the MVP can follow once customers ask for more.

How does AI change the cost?

AI coding tools make writing code faster, and that reduces the effort for the routine parts of an MVP: forms, list views, standard integrations and tests. They do not remove the need for someone to decide what to build, design the data model, review security and make the product work reliably under real use.

That is why a prototype built entirely with AI tools can look finished and still need significant work before launch. If you already have one, read our checklist for taking a vibe-coded app to production before you estimate what is left.

How do you scope version one?

A good scope fits on one page. Work through these steps before you ask anyone for a quote:

1. Write down the one job. One sentence: who the customer is and what they must be able to do. If you need two sentences, you may have two products.
2. List the user types. For each one, note what they need to see and change. Every extra type is a cost driver, so challenge each one.
3. Map the core journey. From sign-up to the moment the customer gets value, step by step. Anything outside that journey is a candidate for later.
4. Name the integrations. Which outside systems must version one talk to, and which could wait behind a manual export?
5. Decide how money moves. A simple subscription, one-off payments, or payouts to other people. Each is a different amount of work.
6. Mark what is still unclear. Unknowns are normal. Listing them lets a team quote the clear parts at a fixed price and phase the rest.
7. Write the "not now" list. Features you want but will not build yet. It protects the scope as much as the feature list does.

How should you budget for version one?

Plan for three things, not one:

1. The build itself. The quote for version one.
2. The first months after launch. Real users find problems that testing does not. Keep room in the budget for fixes and small improvements, or agree a monthly plan such as Care & Growth.
3. Running costs. Hosting, email, payments and other services charge monthly fees. For most MVPs they are small compared to the build, but they are not zero.

What should you ask before you accept a quote?

A good quote answers these questions in writing:

• What exactly is included, and what is explicitly left out?
• Is the price fixed, or is it an estimate? If it is phased, what does the first phase deliver?
• Who owns the code and the accounts from day one?
• How will you see progress, and how often?
• What happens after launch, and how is support arranged?

At Smitheo, you get a written quote before any work starts. After a short scoping call it is either fixed-price or phased with the first phase fixed, and the start date is agreed in the quote.

What is the next step?

If you have an idea and some evidence that people want it, send us a brief with your one-page scope, or with the questions above if you have not written it yet. We will tell you honestly whether an MVP is the right first step or whether a smaller one would prove the idea faster. You can also read more about MVP development or see all our services.