MVP development for startups: what it is, what it costs, and how to not waste the first version

1. What an MVP actually is

A minimum viable product is a working version of your product that delivers the core value to a real user, and can be put in front of them this quarter. The test of an MVP is not how impressive it looks. It is whether it answers a question you cannot answer by thinking harder.

For a founder, that question is almost always one of these three:

• Will people sign up? Does the problem hurt enough that a stranger gives you their email or their card?
• Will they come back? Is this a habit, or a one-time curiosity?
• Will they pay? And at what price does the maths work?

An MVP is a machine for answering exactly one of those — as cheaply and as fast as honestly possible. Everything else is either preparation for scale or decoration.

2. Why "viable" is the hard word

"Minimum" is easy to argue about. "Viable" is where founders and builders genuinely disagree, and where money is usually lost.

Viable means a real customer can complete the core job without you standing next to them explaining it. Not a demo, not a prototype where the third button is fake, not a form that emails you and you do the work by hand — although that last one is a legitimate first step, as long as everyone knows it is scaffolding.

If a paying customer would need you personally in the room for the product to work, you have built a service, not a product. That's fine — but it is a different business, and you should price it that way.

The practical version of viable: a stranger lands on your page, understands what this is, signs up, does the main thing, and gets the outcome. If any step needs a phone call, it is not yet your MVP.

3. The five decisions that decide the outcome

In a well-run MVP build, almost all the risk is concentrated in five decisions made in the first week. Get them right and the rest is execution.

Decision one: the single user

Not a market. A person. "Independent physiotherapists with one clinic" is a user. "Small businesses" is a wish. Write down three specific people you could call this week; if you can't, the scope is not ready.

Decision two: the one job

The job your product does for that person, in one sentence, from their point of view: "gets my no-shows filled without me texting people all day." If your sentence has an "and" in it, you have two products.

Decision three: what you will do by hand

The strongest MVPs are carefully manual behind the curtain. Approvals, matching, report writing, onboarding — done by a human on your side, automated later. This is where you buy speed most cheaply, and it has no effect on how the product feels to the customer.

Decision four: the platform

Web first, almost always. A responsive website works on every phone, ships in a day, and needs no app store review. Native apps exist to access device features and to be on a home screen; most first versions need neither. If your idea genuinely needs the camera, background location, or offline use, say so in week one — that is a real cost increase.

Decision five: the definition of done

Written as numbers before work begins: "20 paying customers in 30 days", "500 sign-ups from one channel", "average return within 7 days above 30%". Without a number, "done" will drift, and the project will end whenever the budget does.

4. What MVP development costs

Costs below are 2026 ranges for a working, launched first version — not a prototype, and not the full product. They assume a single core flow, one user type, and payments if the model needs them.

Path	Typical cost	Time	Best for
No-code / low-code build	$0 – $5,000	1–4 weeks	Directory, booking, membership, simple marketplace
Freelance developer	$8,000 – $30,000	6–12 weeks	One clear flow, founder can design and manage
Small studio (like ours)	$20,000 – $60,000	4–8 weeks	Design, build, and launch with one accountable team
Development agency	$60,000 – $150,000+	3–6 months	Regulated industries, complex integrations, big teams

The spread is not mainly about quality of code. It is about coordination: the more people between you and the person writing the software, the more you pay for meetings. A four-person agency charging for account management, project management, and design review is not cheating you — it just costs more to run than two people who ship every week.

For a deeper breakdown, including what pushes a build from the low end to the high end, see how much it costs to build an app.

5. How to spot a padded scope

Founders are usually quoted for the product they described on the call, not the version that would answer their question. These are the patterns worth pushing back on.

• An admin dashboard in v1. You can run the first version from a spreadsheet and a database console. Ask what it costs to leave it out — often 15–20% of the project.
• Both a web app and native apps. Two extra codebases, two review processes, double the surface for bugs.
• Full user roles and permissions. Most first versions have two roles: you, and the customer.
• Integrations nobody has asked for. Every integration is a dependency that breaks. Ship with the one your users already live in.
• "Scalable architecture" as a line item. You are not scaling yet. You are learning. These are opposite investments, and you can afford the second one.

The question that separates good builders from accommodating ones: "What would you cut to launch in half the time, and what would we lose?" If the answer is "nothing can be cut", you're talking to someone selling hours rather than outcomes.

6. What "done" should mean

An MVP build is finished when these are all true — not before, and not much after:

• It runs on your own domain, and it is fast on a phone with average signal.
• A stranger can go from landing page to completed core action without help.
• Money can move, if money is part of the model, into your account.
• You can see what happened: sign-ups, usage, drop-off.
• You can contact the people who used it.
• You have the code, the accounts, and a written walkthrough.

Notice that none of these are about features. They are all about the product being real and being yours.

7. The mistakes that waste the first version

Building before talking

Ten conversations with your target user will change the scope more than any amount of planning. If you cannot name five people who have the problem, the next step is not development — it is conversations.

Confusing "launch" with "announce"

A launch is not a Product Hunt post. It is putting the product in front of twenty people who have the problem this month. Most MVP failures are distribution failures wearing a product costume.

Redesigning before selling

The first version looks fine. It converts or it doesn't. Fixing conversion is a copy and flow problem long before it is a visual one.

Keeping the build in one person's head

If the only person who understands the system is unavailable next month, you have not bought an asset. Ask for documentation, and ask whose accounts the infrastructure sits in — the answer should be yours.

Never deciding

The most expensive MVP is the one that's still "almost ready" after nine months. A mediocre product shipped in six weeks teaches you more than a beautiful one shipped in a year.

Where to go next

If you're weighing how to build it — with no-code tools, a freelancer, or a studio — read how to build an app with no coding experience. If budget is the open question, start with the cost breakdown.

And if you want a second opinion on a scope you've already been quoted, send it over. Reading a spec takes us an hour and it has saved founders more money than any other hour we spend.