What fits in a first MVP, and what it costs in Germany

I'm not going to give you my own price table. What I can do is point you at two guides that agencies have published, and tell you how to read them. Both are agency sources. They come from companies that sell MVP development, and they describe asking prices in Germany, Austria and Switzerland (the DACH region). Neither is a market statistic.

The first is from happycoding, a Berlin agency, published on 7 October 2026. It says most agencies in the DACH region quote EUR 15,000 to 50,000 for an MVP, and that published ranges run from about EUR 8,000 to 250,000 once you include very lean and very complex projects. It cites another agency, TJ Labs, for a landing page with a waitlist at EUR 3,000 to 8,000 and for Berlin hourly rates of EUR 95 to 145. For freelancers it quotes a median of EUR 90 per hour in software and web development, from freelancermap's Freelancer-Kompass 2026.

happycoding adds its own caveat, and I think it's the most useful line in the guide: these are vendor statements, and hardly any of the pages it reviewed cite a source.

The second is from decivo, a studio that also sells this work, last updated on 20 October 2026. It gives DACH agency rates as EUR 95 per hour at the lower quartile, EUR 120 at the median and EUR 150 at the upper quartile. It also publishes ranges per product type, taken from agency figures it collected for its own cost calculator. Each line below is lower quartile, median, upper quartile:

• Internal tool: EUR 8,000, 15,000, 30,000
• Web app MVP: EUR 15,000, 27,500, 40,000
• Native mobile app MVP: EUR 25,000, 45,000, 80,000
• AI product MVP: EUR 35,000, 65,000, 110,000
• B2B SaaS MVP: EUR 40,000, 60,000, 95,000
• Two-sided marketplace MVP: EUR 45,000, 70,000, 120,000

Two things to notice. The same word, MVP, covers EUR 8,000 and EUR 120,000. And the hourly rate explains only part of it. Here's my own arithmetic, not the sources': at decivo's median rate of EUR 120, the median web app MVP of EUR 27,500 is about 230 hours, a bit under six weeks of one person's full-time work. Every feature you add is more of those hours.

None of these figures covers running the product afterwards. decivo says 15 to 20 percent of the project price per year is common for maintenance. happycoding is sceptical of percentage rules and suggests counting hours, two to five a month for a small web app in its experience. Both pages get updated, so check them before you quote any of this to someone else.

An MVP is a test with real users. It's there to answer one question, usually "will people do this, and will they come back?". It doesn't have to prove the whole platform you have in your head.

An agency prices effort and risk. Effort grows with every screen, every user role and every connection to another system. Risk grows when nobody has written down what "done" means, and an agency that feels risk adds a buffer.

So before you talk about money, write one sentence: who is the user, what is their problem, and what is the one action that counts as success. If you can't write that sentence yet, the scope isn't ready to be priced.

A made-up example: a booking tool for a small pilates studio. The user is a client of the studio. The problem is that booking means phoning during opening hours. Success is a confirmed booking without a call. That can be priced. "A platform for the fitness industry" can't.

Here's the list I'd start from. It has five lines.

One user type. You serve one role well. Each extra role brings its own login, its own permissions, its own screens and its own support questions.

One core flow, end to end. A stranger can arrive, understand the offer, do the main thing and get a confirmation, without you standing next to them. Login, search and notifications go in only if that flow can't work without them.

Payments only if paying is what you're testing. If the open question is "will people pay?", build payment. If it's "do people understand the offer?", a waitlist or a manual invoice answers it for less. happycoding cites vendor figures of EUR 3,000 to 6,000 for a payment integration, so it's a line worth questioning.

Admin is a spreadsheet. No custom admin panel yet. You export the data and work through the rows by hand. Your users never see this part, and with twenty customers you won't mind.

Basic analytics. After launch you need to be able to say how many people arrived, how many started and how many finished. That's enough to decide what to build next.

Made-up example: a service that collects applications for a grant. One type of applicant fills in one form. The owner reviews the entries in an exported spreadsheet. Three numbers get counted. That's a version one.

The cut list matters as much as the feature list, and it has to be written down. Anything you haven't named as "out" will try to sneak back in during the build.

Cutting isn't the same as cancelling. Each of these comes back as its own milestone once the first flow has shown that people use it. I'd want a reason to pull one forward, and "the core promise doesn't work without it" is the only reason I'd accept.

Made-up example: a reporting product. Version one has one report format, one default look and data typed in by hand. More formats and automatic connections come after you know that anyone wants the report.

• A second user role. Serve one side first and handle the other side by hand.
• Two native apps. A web flow that works on a phone teaches you the same thing and is cheaper to change.
• Settings and themes.
• Exports.
• Integrations with other systems, unless the product is the integration.

If you know what makes a quote go up, you can trade scope against budget on purpose. happycoding's guide lists five drivers: integrations, roles and tenants, payments, enterprise login, and compliance evidence. I'd add five, and most of them have more to do with you than with the software.

Integrations. Each connection to another system needs keys, limits and handling for the moment it fails. happycoding's advice is to connect read-only first and add writing back later, because writing is where the error handling piles up.

Roles and tenants. A tenant is a customer company whose data must stay separate from every other company's. If you sell to businesses, that separation goes into the data model from the start, and it costs.

Screens and states. Every screen has an empty state, a loading state and an error state, and each one has to be designed, written and checked.

Content and data. Agencies often assume you'll deliver finished text and clean data. If you don't, somebody does that work, and it turns up as hours.

Design starting point. A logo, colours and two or three reference sites shorten the design phase. A blank page lengthens it.

How fast you decide. A team that waits days for each answer loses time, and somebody pays for it. One person on your side who can say yes or no in writing is part of cost control.

Who the launch is for. Ten friendly pilot users forgive rough edges. A public launch with paying strangers doesn't. Say which one you mean before you ask for a number.

Made-up example: two founders both ask for "a simple marketplace". One means a landing page, a request form and matching done by hand in a spreadsheet. The other means accounts for both sides, chat, payments and reviews. The first is close to a landing page with a form. The second is what decivo's table prices as a two-sided marketplace.

The hourly rate tells you the unit price. The billing model tells you who pays when the estimate turns out wrong, and that matters more.

With fixed milestones, the agency carries that risk, but only for the scope that's written down. Scope stays, price stays. With hourly billing, you carry it: if the work takes longer, the invoice is higher.

Both agency sources land in the same place. decivo calls a fixed price usually the safer choice for a clearly bounded scope, on the condition that there's a written scope document. happycoding recommends a fixed price for a first version with a fixed scope, and time and materials with a budget cap for what you learn after launch. happycoding also gives the German legal background, a contract for work versus a contract for services. I'm not a lawyer, so if that distinction matters for your contract, ask one.

I prefer fixed milestones for a version one, for a simple reason: a first version should be small enough to define. If nobody can write its definition of done on one page, it's too big or too vague, and the cure is to cut it down. Switching to hourly doesn't fix that.

A definition of done names the flow, the user, the steps someone will click through to accept it, and the list of what's out. Test it on a person who doesn't know the project. If they can't tell whether the milestone is finished, rewrite it.

The rule that keeps a fixed price fair to both sides: a change in scope re-prices the next milestone before work starts. You write the request down. Then you agree, in writing, whether it replaces something or becomes a new milestone. Nothing gets added quietly inside a milestone that's already running.

Hourly billing still has its place: a paid discovery phase when the scope really is open, or small changes after launch. Ask for a cap and a weekly note on what was done. More on how I work is under product engineering.

Most of it is habits, and none of them need technical knowledge.

Before the first milestone starts, check that the accounts are in your company's name. I've written up the six things to own from day one.

• One person on your side decides, and decides in writing.
• A milestone is frozen once it starts. New ideas go on a list for the next one.
• Ask for a link to a working version early, and click through the flow yourself every week.
• Report problems in one place, with the steps to reproduce them.
• Keep the cut list where everyone can see it. If something comes in, something else goes out, or the next milestone grows.

The prompt below works in any AI assistant. Fill in the brackets in your own words and paste it. It should come back with one sentence, an in list, an out list and acceptance steps, all on one page.

Read the first sentence of the result before anything else. If it runs to three lines, the idea is still too wide, so narrow it and run the prompt again.

Then send that page, unchanged, to every agency or freelancer you ask for a quote. They all price the same box, and you can compare the numbers. The assistant doesn't know what things cost, which is why the prompt forbids it from guessing.

Made-up example of what it does: "a platform for local services with chat and reviews" comes back as "a customer can request one service and receive a confirmation", with chat, reviews, the provider login, exports and themes on the cut list.

Goal: Turn my rough product idea into a one-page scope for a first MVP, with a cut list.

Inputs: My idea in plain words: [describe the user, their problem, and what should happen]. My limits: [budget range, who version one is for, and what text and data I will deliver myself].

Constraints: Use plain words. Keep version one to one user type and one core flow from start to finish. Include payments only if testing whether people pay is the point. Admin is a spreadsheet export. Analytics is three counts: arrived, started, finished. Put a second user role, native apps, settings, themes, exports and integrations on the cut list unless the core promise cannot work without them. Do not invent prices, hours, dates or vendor names. Where you would need a fact you do not have, write "open question".

Definition of done: One page containing (1) the product in one sentence that names the user, the problem and the single success action, (2) an IN list covering arrival, action and confirmation, (3) an OUT list with one reason per item for why it can wait, (4) acceptance steps that a non-technical person can check by clicking, and (5) the open questions that block a fixed milestone quote.