How much does an MVP cost? What founders pay, and why

Most of the MVPs we build cost between €15k and €50k and take six to twelve weeks. Where yours lands depends on five decisions, and most of them are yours to make.

That range is wide on purpose. “MVP” gets used for everything from a landing page with a waitlist to a funded company’s first production release, and a single number would be misleading. What follows is how the price is actually set, where budgets go wrong, and what you should get for your money, so you can read any quote, ours included, with confidence.

What an MVP is, and what it isn’t

A minimum viable product is the smallest version of your product that proves the business. Not the smallest version you can build: the smallest version that lets real customers do the one job you exist for, so you can learn whether they want it, use it and pay for it.

That definition does most of the work in controlling cost. If a feature doesn’t help prove the business, it isn’t in the MVP. It isn’t cut, it’s scheduled for later, once the first version has told you whether it’s worth building.

It’s also worth being clear about what an MVP isn’t. It isn’t a prototype, which shows how the product would work without being the real thing. And it isn’t a proof of concept, which tests whether something can work at all. If you’re not sure which one you need, we’ve written a separate guide to that choice.

The five things that set the price

1. How many core journeys

A journey is one complete thing a user does, from start to finish: sign up and set up an account, book an appointment, send an invoice, get a report. Most MVPs need one or two core journeys, plus the onboarding that gets people to them. Every additional journey adds design, build and testing, and it’s the biggest driver of cost by far.

2. How many platforms

A responsive web app works on every device and is usually the fastest route to real users. Adding native iOS and Android apps can nearly double the build. Unless your product only makes sense on a phone, such as something that uses the camera, location or notifications all day, start on the web and add mobile once people are using it.

3. How it’s built

There are three honest options, and a good partner will tell you which one fits before you commit:

• No-code tools get a working product live fastest and cheapest, and are right for many early products.
• Low-code mixes visual tools with custom code where the product needs it.
• Custom code costs more up front, and is the right choice when the product depends on complex logic, real-time data or scale from day one.

The wrong choice is the one that forces a rebuild the moment you find traction. The question isn’t which is cheapest today, it’s which gets you to real users without costing you a second build in year two.

4. Integrations and data

Payments, calendars, email, CRMs, maps and AI models all come with ready-made services, and connecting to them is usually quick. The cost rises when you need to integrate with systems that don’t have good APIs, move sensitive data between them, or build AI features whose output people have to trust and act on.

5. Compliance

Some products carry obligations from the first release. Health products may need NHS DTAC evidence or HIPAA-ready infrastructure. Financial products bring security reviews and, in the EU, the European Accessibility Act. Building for these from the start is cheaper than retrofitting them, but it does add to the first budget.

What that means in numbers

Here’s how our own projects tend to fall, so you have real reference points:

• A tested prototype to validate the idea or raise on it: €8k to €20k, in three to six weeks. Often the right first step.
• A focused web MVP with one core journey: from about €15k.
• A web app with accounts, payments and a basic admin: typically €25k to €40k.
• Web and mobile, heavier integrations or AI features: €40k to €50k and sometimes beyond.

Freelancers can come in lower and larger agencies considerably higher. The price matters less than what’s included: a fixed scope, tested designs, a working product, measurement and a team still in the room after launch.

Where MVP budgets go wrong

Almost every overrun we’ve been asked to rescue comes from one of these:

• Scope that grows during the build. Every “small” addition is a design, a build, a test and a new edge case. Discovery exists to agree the list before the clock starts.
• Building the admin before the product. For your first hundred customers, you can do most admin by hand. Build the part customers see first.
• Two platforms before one works. Launching on web, iOS and Android at once triples the surface you have to get right.
• Skipping testing with real users. It feels like a saving until you rebuild a flow that people couldn’t use.
• No analytics at launch. An MVP exists to teach you something. Without measurement, launch day teaches you nothing.

How to spend less without shipping less

• Test a prototype first. A few weeks and a fraction of the budget will tell you whether the core journey works before you pay to build it.
• Do things by hand. Manual onboarding, emailed reports and a spreadsheet for admin are perfectly respectable in version one.
• Use what already exists. Authentication, payments, email and hosting are solved problems. Don’t pay to solve them again.
• Pick one platform. Usually the web.
• Fix the scope, then the price. A fixed scope makes a fixed price possible, and a fixed price protects you from the overrun.

What you should get for the money

Whoever builds your MVP, the engagement should include:

• A signed-off scope, including what waits for version two
• Designs tested with the people you’re building for
• A working product, live with real users, not a demo
• Analytics set up from the first release
• An interface that meets accessibility standards, which enterprise buyers increasingly ask for
• Ownership of every design file and line of code
• Support in the weeks after launch, when the first real feedback arrives

Fixed price or time and materials?

For a first version, a fixed price after a short discovery is usually the better deal for a founder. It forces the scope conversation early, and it moves the risk of estimation onto the people doing the estimating. Time and materials makes more sense once the product is live and the work becomes a continuous cycle of improvements.

The short version

Decide the one job your product must do, build that on one platform, and prove it with real users before you build anything else. That is how an MVP stays an MVP, and how its cost stays predictable.

If you’d like a first read on your idea, our MVP development page explains how we scope and build, and a proof of concept is often the right place to start. Tell us where you are and you’ll get a suggested starting point within two working days.