MVP Scope: What to Build, What to Skip, What It Costs

You have a product idea, a budget that will not stretch forever, and a developer or agency asking "what exactly do you want?" The danger is not building too little. It is building a small version of everything, so you spend five months and still cannot tell whether anyone wants the core thing.

This post is for a non-technical founder. It covers what belongs in an MVP, what you should skip deliberately (and when each skipped item comes back as a bill), and what drives the cost.

Start with one promise, not a feature list

An MVP is the smallest thing that tests one risky belief about your business. Write that belief as a sentence:

"Clinic managers will pay to stop chasing missed appointments by phone."

Everything in the build either helps test that sentence or it waits. Three questions sort most features:

Does a customer have to do this to get the promised result? Build it.
Does it make the result nicer, faster or prettier? Skip it for now.
Does it protect you from something that would be expensive to undo (lost data, leaked data, money handled wrongly)? Build the simple version.

The third question is the one founders miss. Skipping is fine. Skipping the things you cannot take back is not.

What to build

The one core flow, end to end. A customer arrives, does the thing, gets the result. It can be ugly. It must work every time for the first 20 customers.

Login and basic account safety. Use a proven login provider or the framework's built-in one. Never let anyone build password handling from scratch.

A real database with backups switched on. Not spreadsheets pretending to be a database, and not a database nobody can restore. Managed databases do backups for you; just confirm they are on.

Payments through a hosted provider, if you charge. Let Stripe or similar handle card data. You do not want to touch it.

Basic error visibility. You should find out something is broken before your customer emails you. This is an hour of setup, not a project.

An admin view for you. A plain page where you can see users, fix a wrong record, and refund someone. Founders consistently underestimate how much of the first six months is manual support.

One environment you can redeploy in minutes. Code in version control, one command or button to deploy. If only one person can release, you have a risk, not a process.

What to skip, and when it comes due

Skipping is a loan. Here is each common skip and the event that triggers repayment.

Skip this	It comes due when
Native mobile apps	Customers ask for push notifications or offline use. A mobile-friendly website is enough until then.
Multiple user roles and fine-grained permissions	A second customer organisation needs to hide data from the first, or a customer's security team asks who can see what.
Automated test coverage on everything	Releases start breaking things you already fixed. Test the money and login paths from day one; the rest can wait.
Microservices, Kubernetes, fancy scaling	Almost never at MVP stage. See the boring cloud stack.
Custom analytics dashboards	You have enough users to make a decision from. Until then, a simple event tool and a weekly look is fine.
Third-party integrations (CRM, accounting, etc.)	A signed customer makes it a condition of paying. Build it then, not before.
Perfect design and branding	Conversion on your landing or signup page, not looks, tells you when to invest.
Performance tuning	Pages or reports slow down noticeably, usually when data grows 10x or more.
Compliance programmes (SOC 2 and similar)	A buyer asks for it in a deal. Basic security hygiene now makes that later project far cheaper.

The pattern: skip breadth, never skip safety. Customer data, money and backups are the floor.

For your CTO or engineers

Skip the architecture astronomy, but leave seams. Keep business logic out of controllers and templates, put multi-tenancy (an organisation_id on every row) in the schema even if you only have one customer, keep third-party calls behind one module each, and write migrations rather than editing the database by hand. These cost days, not weeks, and they are what separates "we will refactor" from "we will rewrite". The same idea is covered in MVP to production: what your backend needs before scale.

What an MVP costs, and what drives it

I will not give you one number, because anyone who does without knowing your scope is guessing. Market rates vary widely by country, by whether you hire freelancers, an agency or in-house, and by seniority.

What matters more is the drivers. In rough order of impact:

Number of distinct user types. A product with customers, admins and a third-party partner role is closer to three products.
Number of integrations. Each outside system (payments, email, calendars, other vendors' APIs) brings edge cases, test accounts and failure handling.
Anything that handles money, health data or children's data. Rules, audit trails and security reviews add real time. See the FinTech and healthcare material on this site if you are in that world.
Platforms. Web only is the cheapest. Web plus iOS plus Android roughly multiplies the front-end work.
Changing scope. The most expensive line item in most failed MVPs is rework from decisions changed mid-build.
Who builds it. An experienced small team usually costs more per hour and less per outcome. A cheap build that needs rewriting is the costliest option.

Ongoing costs surprise first-time founders: hosting, monitoring, email and SMS, app store fees, and above all the engineer time to fix and change things after launch. Plan for the build to be the start of spending, not the end.

Example (illustrative)

Take a hypothetical founder building a booking tool for independent physiotherapists. The belief to test: "Clinics will pay monthly if patients can book and get reminders without calling."

Scope A, the trap: patient app on two platforms, clinic dashboard, therapist calendar sync, insurance billing, analytics, multi-clinic permissions. An estimate of 6 to 9 months with a team of 4 would not be surprising.

Scope B, the MVP: a mobile-friendly web booking page, SMS reminders, a simple clinic view, card payments through a hosted provider, an admin page for the founder. Rough guess: 8 to 12 weeks with 2 engineers.

Same belief tested, in roughly a third of the time. If 10 clinics pay, the founder then adds calendar sync because customers are asking, not because it sounded sensible. These numbers are made up to show the shape, not a quote.

When NOT to do this

Do not use "MVP" as an excuse to ship something unsafe. If you hold sensitive data or move money, the safety floor is part of the minimum.
Do not build an MVP at all if you can test the belief without code. A landing page, a manual service behind a form, or a no-code tool will answer some questions in a week.
Do not skip scoping because you "already know" what customers want. If you have not talked to ten of them, the MVP is a guess with invoices.
Do not keep patching an MVP indefinitely once revenue depends on it. At that point you need to stabilise it. See the scaling roadmap.

Common mistakes

Treating the MVP as a smaller version of the final product instead of a test of one belief.
Letting the first developer choose the stack with no review, then discovering nobody else can maintain it.
Not owning your accounts: code repository, cloud account, domain and app store accounts should be in your company's name, not the contractor's.
No admin tooling, so every small data fix needs an engineer.
Skipping backups and never testing a restore.
Adding "one more feature" to every weekly meeting.
Judging cost by hourly rate rather than by what is delivered and how easy it is to extend.

Checklist

Want a second opinion on your MVP scope?

If you have a scope document or a half-built product and want to know what to cut, what to protect, and whether the quote you received makes sense, that is what my MVP to Production Systems work is for. Book a free 30-minute technical review through the contact page and bring whatever you have.

FAQ

How long should an MVP take to build?

Often a matter of weeks to a few months, depending on scope. If a plan runs past about four months before any customer touches it, the scope is probably too wide.

Should I hire an agency, freelancers or a technical co-founder?

It depends on how much you will keep changing the product. Agencies suit a well-defined scope; a technical co-founder or fractional technical lead suits a product still being discovered. Whoever builds, make sure you own the code and the accounts.

Can an MVP be turned into the real product?

Yes, if the seams were left in: clean data model, separated logic, deployment you can repeat. If not, you will pay for a partial rewrite. Technical debt can be a deliberate tool when you track it.

What is the one thing I should never skip?

Backups you have actually restored, and not storing card or credential data yourself. Both are cheap early and brutal to fix after an incident.