The short answer: with me, a focused MVP starts from €5,000 fixed and takes 2–4 weeks. A simpler marketing site or landing page runs from €1,500. Larger products don't get one big quote — they get scoped in phases, so you pay for a working, shippable slice at a time instead of a promise.
That's my answer. The honest longer answer is that "how much does an MVP cost" has no universal number, because the price is not set by the technology — it's set by how the scope is defined. This article explains where the wild differences in quotes come from, what a €5,000-tier build realistically includes, and how to cut cost without cutting your chances.
Why MVP quotes vary from €5,000 to six figures
Ask five vendors to price "an MVP" and you may get five numbers that differ by 10–50x. That does not necessarily mean someone is lying. Each vendor may have priced a different product.
Scope definition is the real product. "An app where users book appointments" sounds like one sentence, but every clarifying question adds a chunk of work:
- Auth — email/password only, or Google/Apple login, password reset, email verification?
- Payments — a single Stripe checkout, or subscriptions, refunds, invoices, VAT handling?
- Roles — one user type, or customers + providers + admins, each with different views?
- Admin panel — do you manage data in the database directly, or need a UI for a non-technical person?
- Integrations — calendar sync, SMS notifications, a CRM, an accounting tool — each is its own mini-project.
- Mobile — responsive web, or native apps in two stores with two review processes?
Each "yes" can add days of work. A vendor who assumes all yeses quotes a platform. A vendor who assumes all noes quotes a prototype. Both may call it "your MVP."
Who is quoting also changes the number:
- Agencies quote teams. An agency proposal may include project management, design, multiple developers and QA because the team is its unit of sale. You are paying for that structure, which can cost more per month than a focused MVP delivered by one specialist.
- Freelancer platforms quote hours. Hourly billing can look cheap per unit, but without a cap the total is open-ended: the longer it takes, the more it costs you.
- Fixed-price builders quote outcomes. A written scope, a price, a deadline. The builder carries the estimation risk for the agreed scope. This is how I work, and it is the model I would prefer as a buyer.
So before comparing numbers, compare what the numbers are for. A €5,000 quote and a €50,000 quote are usually not competing offers — they're different products wearing the same name.
What a €5,000-tier MVP realistically includes
Honesty requires drawing this line clearly, so here it is.
A focused MVP at the starting price typically covers:
- One core flow, built properly end to end — e.g. visitor signs up, does the one thing your product promises, and pays for it
- Clean, responsive UI (not a template dumped on you, not a design-agency art project either)
- Basic auth if the flow needs it
- One payment path (e.g. Stripe checkout or subscription)
- A simple way for you to see and manage the data
- Deployment, domain, SSL — live on the internet, not "works on my machine"
- Analytics wired in so you can actually learn from launch
What usually pushes a build into phases instead:
- Multiple user roles with different dashboards (marketplaces are the classic case)
- Real-time features — chat, live updates, notifications infrastructure
- Complex integrations (ERPs, banking APIs, healthcare systems, anything with a compliance layer)
- Native mobile apps
- Heavy custom logic — matching algorithms, scheduling engines, pricing calculators with many edge cases
None of this means "impossible" — it means we split it. Phase one ships the riskiest, most valuable slice in weeks; each next phase is priced and scoped only after the previous one is live and teaching you something. You never pre-pay for month four based on month-zero guesses.
If your idea fits the focused tier, the MVP offer is here with the process spelled out.
The single biggest cost lever: build for your riskiest assumption
Founders often focus on negotiating the rate. A larger cost lever can be what you decide to build first: the smallest thing that tests your riskiest assumption.
For many products, an early assumption worth testing is not "can this be built" but "will anyone pay." That can often be tested before funding a full build:
- Landing page + real payment button — describe the product and take actual pre-orders or deposits. If visitors will not click "pay" on the page, that is a reason to question whether a full app deserves funding yet. It can go live in days at the landing-page starting price.
- One-flow MVP — the single core action, done for real, with real payments. This is the €5,000-and-up territory.
- Full platform — roles, admin, integrations, mobile. Justified only after the core flow has paying users, because now you're building for demand you've measured, not imagined.
The expensive mistake I see most often: skipping straight to level three. Six months and a serious budget later, the founder learns something a two-week landing-page test would have shown for a fraction of the money. Cutting scope isn't settling for less — it's buying the same learning sooner and cheaper.
A useful exercise before requesting any quote: write down the one sentence you need to hear from a customer ("yes, I'll pay €X/month for this"). Then ask what the minimum build is that could make a real customer say it. That's your MVP. Everything else is phase two.
AI prototypes: cheap to start, expensive to productionize
In 2026 you can get a working-looking prototype out of Lovable, v0 or Bolt in an afternoon, sometimes for the price of a subscription. That has genuinely changed the early stage — and it deserves an honest assessment rather than either hype or dismissal.
When an AI prototype is enough:
- Showing investors or early customers what you mean, visually
- Testing whether a UI concept makes sense before committing to it
- Internal demos and clickable mockups
- Validating interest before any real build
Where it commonly stalls:
- Real users. Prototypes that work for one polite tester fall over under concurrent users, bad input, and edge cases nobody prompted for.
- Payments. Taking real money means webhooks, failed-payment handling, refunds, and tax — the part AI tools skip because the happy path demos fine without it.
- Security and data. Auth that actually protects accounts, permissions that actually restrict access, a database that won't leak. Generated code frequently looks right and isn't.
- Change. The tenth iteration on generated code is where velocity collapses — nobody, including the AI, fully understands what's there anymore.
The trap isn't starting with an AI prototype — that's often smart. The trap is mistaking it for the product and discovering the gap only after announcing a launch date. If you're already holding a prototype that got you this far but can't go further, that exact situation is what AI prototype to production covers: keeping what's validated, rebuilding what has to carry real users and real money.
Budget-wise, treat the prototype as part of your validation spend, not your build spend. It helps answer "is this worth building"; production work still needs its own scope and budget.
Hidden costs founders forget to budget
The build price is not the whole price. These costs are usually modest on their own, but discovering them one by one after launch can turn "€5,000" into a sour memory. Put them in the spreadsheet up front:
- Hosting. A typical early-stage MVP runs on modern platforms cheaply — often near-free at first — but it's a recurring line, and it grows with usage.
- Domain and email. The domain itself is cheap; professional email on your domain is a small monthly cost people routinely forget.
- Third-party APIs. Payments take a percentage of every transaction. Maps, SMS, email delivery, AI APIs — each is metered. Fine at MVP volume, but they must be on the list, because they scale with success.
- Maintenance. Dependencies and security patches require updates, and the first real users may surface issues no test caught. A product is not a one-off purchase; it creates an ongoing commitment.
How I handle this: the written scope you get before paying anything includes the expected running costs, in plain numbers, with the accounts in your name — hosting, domain, payment provider, all of it. You own the infrastructure and the code from day one, so changing developers does not mean losing your product. After launch, you choose: maintain it yourself (it's your code, documented), or a maintenance arrangement with a defined scope. Either option has its terms set out in advance.
Questions to ask before paying anyone
Whether you talk to me or anyone else, these questions separate professionals from expensive lessons:
- "What exactly is included, in writing?" A scope that fits in a text message will expand in an invoice. Insist on a written list of what ships — and, just as importantly, what doesn't.
- "Fixed price or estimate?" An "estimate" is a number that grows. Ask who absorbs the overrun if the work takes longer.
- "When do I see working software?" Weekly demos of the real product, or a big reveal at the end? Big reveals are where budgets go to die.
- "Who owns the code and the accounts?" The repository, the hosting, the domain — in whose name? "Ours, until final payment" is a leash.
- "What happens after launch?" What does a bug fix cost? What's the response time when something breaks on a Saturday?
- "Can I talk to someone you've shipped for?" Portfolios can be decorated. A fifteen-minute call with a past client can't.
Irritation or evasiveness in response to these questions is itself a warning sign.
How the process works with me
For transparency, here's exactly what happens if we work together — this is the checklist above, answered:
- Free 20-minute call. You describe the idea; I tell you honestly whether it fits a focused MVP or needs phasing — including when the honest answer is "start with a landing page test instead."
- Fixed written scope, price, and timeline. Before any money moves, you have a document stating what will be built, what it costs, and when it ships. If it's not in the document and you want it, it's a priced addition — not a surprise.
- Weekly demos. You see the actual product working every week, not slides about it. Course corrections happen when they're cheap.
- You own everything. Code in your repository, infrastructure in your accounts, from the start.
- Replies within 24 hours. During the build and after it. You're working with the person who writes the code — 10+ years of building for the web, 120+ launched projects, based in Warsaw, working with founders across the EU and beyond.
Validate the riskiest assumption before funding the full product
An MVP in 2026 can cost from €5,000 to six figures, and much of the difference comes from scope and delivery model. (For the full ladder from no-code DIY to an enterprise team, including the cost drivers and cost-control choices, see web development cost by budget.) A disciplined approach is to define the smallest build that tests the riskiest assumption, get it live, and use evidence from real users to decide what deserves funding in phase two.
If you want a real number for your idea instead of a range: book the free 20-minute call. You'll leave it with a straight answer — a fixed quote, a phased plan, or an honest "test it cheaper first."