MVP (Minimum Viable Product), Prototype, or Proof of Concept? The Difference and When You Need Each

Proof of concept, prototype, MVP, and pilot often turn up in the same sentence in pitch decks and proposals, yet they answer four different questions. So when you come to us for MVP development, we open the first call with a question of our own: which uncertainty should the result resolve? The answer determines which of the four stages you need:

The right stage follows from the biggest risk in your project; the budget comes second. I'm writing from the builder's perspective: we're a team of seven in Berlin and have completed more than 150 projects. For each stage, you'll find its purpose and outcome, plus timelines and market prices where providers publish them. I'll also walk you through MVP development, two costly mistakes, and the metric that shows whether a B2B MVP holds up.

An MVP (minimum viable product) is the first version of a product that already gives real customers something of value and shows you whether they want it. According to Wikipedia, entrepreneur Frank Robinson coined the term in 2001; Steve Blank and Eric Ries popularized it.

In 2009, Ries defined the MVP as "that version of a new product which allows a team to collect the maximum amount of validated learning about customers with the least effort." The same post contains a more important sentence: "MVP, despite the name, is not about creating minimal products." An MVP is not a stripped-down final product. It is a tool for learning.

Steve Blank tells the story of a small Stanford startup that wanted to sell farmers data about their fields. The plan: buy a drone, a hyperspectral camera, and image-processing software, then spend months integrating them. Blank's advice was to rent a plane or a helicopter and analyze the data by hand. What needed testing was not the technology but whether farmers would pay for the data.

Dropbox also tested demand with a video before shipping any software: according to founder Drew Houston, the beta waitlist jumped from 5,000 to 75,000 people overnight.

Marty Cagan prefers the term "MVP test" for such experiments, so that "people don't confuse an experiment with a product." For him, an MVP has to meet three conditions: people choose to use or buy it (valuable), they can figure out how to use it (usable), and the team can deliver it with the resources available (feasible).

Germany's Gründerplattform, a startup portal backed by the state-owned development bank KfW, draws the line between MVP and prototype at value. In our translation: "Unlike a prototype, which does not necessarily have to work or be ready to sell, an MVP must already deliver value to the customer."

These definitions add up to a four-step process, whether you build in-house or bring in a team for MVP development:

For MVP development, German agencies quote 4 to 12 weeks (decivo, April 2026), 6 to 16 weeks (Wilde-IT, July 2025), or 6 to 20 weeks (TJ Labs, March 2026). TJ Labs attributes the spread to project complexity.

For a working software MVP, decivo and xmethod quote €15,000 to €50,000. There are leaner ways in: according to decivo, an MVP built with no-code tools costs €3,000 to €10,000. TJ Labs puts a mobile app MVP at €35,000 to €90,000 and one with AI features at €50,000 to €150,000. So the MVP label says little about the price; what matters is how you scope the core workflow.

Prototypes and proofs of concept usually come before the MVP. A pilot often comes after it, or runs alongside it when your customers are businesses. All three have one thing in common: they end in a decision, not a finished product.

The Nielsen Norman Group describes a prototype as a hypothesis: a candidate solution to a specific design problem. Prototypes range from a sketch with no clickable elements to a detailed design with real copy. A clickable mockup is what t2informatik calls a click dummy: "a clickable prototype with a very small range of functions" that gets you early feedback from users.

You test with a handful of people: according to Jakob Nielsen, a round with five test users uncovers 85 percent of usability problems. Then you revise the design and run the next round. In the design sprint from GV, formerly Google Ventures, the prototype takes a single day because it only needs to show the surface customers see.

That is why the prototype belongs before the requirements document, not after it. Our guide to custom software explains why an 80-page requirements document written before the first prototype is a classic mistake.

According to decivo, a clickable mockup takes one to two weeks and starts at €3,500; TJ Labs quotes prices from €3,000. For prototypes in general, Wilde-IT estimates 3 to 8 weeks, and decivo prices a coded prototype from €12,500. If you build a clickable mockup yourself, it costs only time: Figma's free Starter plan includes interactive prototypes.

There is a new gray zone: AI app builders like Lovable turn a text description into a working prototype, database included. It looks like a product, but it remains a prototype until operations, permissions, and the data model are sorted out.

According to Wikipedia, a proof of concept (PoC) is "an inchoate realization of a certain idea or method in order to demonstrate its feasibility or viability." It is aimed at your team, your investors, or your IT department, not at customers. Typical questions: Does the ERP system's API deliver the data fast enough? Does a language model reliably recognize the document type?

A PoC usually involves a technical prototype of the core function. In this article, though, "prototype" means the design that users see, as the Nielsen Norman Group describes it. So the clearest way to tell the two apart is by what gets tested: the PoC tests the technology; the user prototype tests how people respond. A successful PoC shows what is possible, but not whether anyone wants it.

For a PoC, providers quote 1 to 2 weeks (decivo), 2 to 6 weeks (Wilde-IT), or 2 to 8 weeks (computech). The German IT firm computech GmbH puts a small PoC at €5,000 to €15,000, a medium one at €15,000 to €35,000, and a large one at €35,000 to €50,000.

Wilde-IT budgets 8 to 30 person-days plus infrastructure. At eight hours a day and €90 an hour, the median rate for freelance software and web developers in the freelancermap survey (July 2026), that comes to €5,760 to €21,600.

A PoC is not just a startup tool. In AI projects, it shows whether the simplest approach is enough, such as a good prompt or search across your own documents; our guide to training your own AI model covers this. Before you replace a legacy system, a PoC proves that a first module can run alongside the old one.

The European Environment Agency's thesaurus defines a pilot project as "a small scale experiment or set of observations undertaken to decide how and whether to launch a full-scale project." A pilot runs under real-world conditions, but only at one site, in one department, or with one customer. In practice, the term covers three different things:

We have not found a reliable market range for pilots: duration and price depend on what is being piloted and on the agreement with the customer. One thing is certain: without an agreed end date, a pilot turns into a permanent stopgap.

The table sums up the four stages. Read down a column to understand one stage, and across a row to compare all four on one criterion. Durations and costs are published provider figures, not statistics, and they vary widely.

All figures retrieved October 10, 2026; the dated provider figures were published between July 2025 and May 2026. You'll find the sources with each stage in the text above. Our guide to software development costs explains why quotes for the same requirements can differ by a factor of 10.

Let your biggest risk decide. If you don't know whether the technology will hold up, start with a PoC. If you don't know whether people will understand the solution, start with a prototype. If you don't know whether anyone will pay, start with an MVP.

So PoC, prototype, MVP, and pilot are not a checklist you have to work through in order. Many web products don't need a PoC because their technology is proven. And no clickable mockup proves that anyone will pay. Whether you end up with a website, a web app, or a portal is a separate question; our guide Website, web app, or customer portal answers it.

Both mistakes have the same root: someone confuses a stage with the finished product. The first scopes the MVP the wrong way; the second overrates the PoC.

A common fallacy takes "minimum" literally: someone cuts the feature list of the planned final product in half and calls what's left an MVP. The result is software that does a little of everything and nothing completely. It also answers no question, because nobody can complete a workflow with it.

Cagan's three conditions help you draw the line: valuable, usable, feasible. One core workflow done completely beats five workflows done halfway. Michael Seibel of Y Combinator advises tying the scope to a fixed deadline, three weeks in his example. If time runs short, you cut the unimportant features first and, if necessary, important ones too.

An MVP may look unfinished, but its foundation should hold in case the numbers come out in favor of the product. That is why we build MVPs on a stack that can grow with them, such as Supabase on PostgreSQL. Then a rebuild is only on the table in three cases: a fundamental pivot, a late switch from password logins to enterprise single sign-on, or taking over someone else's prototype.

The opposite mistake: a PoC works, so it goes live. But it was built to answer a single question, often with no permission model, no tests, and no data model built to last. The technology readiness level scale used in EU research funding puts "experimental proof of concept" at level 3 of 9. A system proven in an operational environment sits at level 9.

Back in 1975, in The Mythical Man-Month, Fred Brooks warned against shipping the first, throwaway system to customers. Doing so "buys time, but it does so only at the cost of agony for the user."

In a July 2024 forecast, Gartner predicted that at least 30 percent of generative AI projects would be abandoned after proof of concept by the end of 2025. Gartner named poor data quality, inadequate risk controls, escalating costs, and unclear business value as the reasons. A pure feasibility test doesn't check three of those four at all.

AI app builders invite the same mistake. According to the Lovable documentation, Lovable Cloud is built on the open-source foundation of Supabase, and you can export the schema and data. But there is no one-click migration to your own Supabase project.

Moving the database alone, Lovable notes, doesn't carry over authentication, file storage, Realtime, or Edge Functions. You have to set up AI features and third-party integrations again at the destination with your own accounts, or replace them.

Throwing code away isn't failure, as long as you plan for it. Martin Fowler calls this "sacrificial architecture": "accepting now that in a few years time you'll (hopefully) need to throw away what you're currently building." His example is eBay: Perl scripts in 1995, a rebuild in C++ in 1997, another in Java in 2002.

So throwaway code can go live, as long as the rebuild is planned from day one. The difference is timing: you decide before the PoC whether its code will live on, instead of finding out after launch that it won't hold up. A PoC proves that something works; a product has to prove it every day.

An MVP is a measuring instrument: it shows whether you are getting closer to product-market fit. Marc Andreessen defined the term in 2007: "Product/market fit means being in a good market with a product that can satisfy that market." When it's missing, Andreessen writes, you can tell from sales: deals take too long, and many never close.

A March 2026 analysis by CB Insights shows how often it's missing. Of 385 venture-backed startups that shut down for an identifiable reason, 43 percent failed at least partly because of poor product-market fit; companies could have more than one reason. The startups in the sample had raised a median of $11 million.

Until product-market fit is proven, keep your team small and flexible: every insight from the MVP can still change the product, and a large team makes each change more expensive.

For products with many users, Sean Ellis came up with a simple test. You ask active users: "How would you feel if you could no longer use the product?" According to First Round Review, companies that struggled to grow almost always came in below 40 percent "very disappointed." Companies with strong growth almost always came in above that mark.

The email client Superhuman stood at 22 percent in the summer of 2017. Focusing on the right user segment brought it to 33 percent, and three quarters of product work brought it to 58 percent. According to founder Rahul Vohra, the test becomes directionally reliable at around 40 responses. With three pilot customers, it tells you nothing.

In B2B, an MVP looks different: few customers, long buying cycles, and buyers who often aren't the users. Seibel considers a "heavy MVP," meaning an elaborate one, necessary only in rare cases, such as heavily regulated industries like insurance and banking. Praise in a demo meeting counts for nothing here. What counts is a commitment that costs the customer something.

In The Mom Test, Rob Fitzpatrick names three currencies for such commitments: time, reputation, and money. Financial commitments include a letter of intent, a pre-order, or a deposit.

Design partners are target customers who help shape the product before launch. According to Bessemer Venture Partners, most practitioners recommend five to twelve of them. In the end, it comes down to a yes-or-no question: per Bessemer, the signal is whether they convert to paying customers, not their feedback.

That's why, for us, the signed pilot agreement is the first hard metric for a B2B MVP. One caveat: under German law, a letter of intent is not automatically non-binding, as the Frankfurt Chamber of Commerce and Industry points out.

The pilot agreement should cover duration, success criteria, the price after the pilot, and a decision date. According to Steve Blank, a good pilot customer knows their problem, is actively looking for a solution, and has the budget or can get it quickly.

The pilot is where procurement questions start. If your MVP processes personal data on the customer's behalf, Art. 28 GDPR requires a data processing agreement. Next come security questionnaires, covered in our article on the trust center, and often a request for enterprise login via single sign-on. A separate guide answers whether Supabase Auth is enough for that.

Still, don't overbuild: an MVP that might be shut down in six months doesn't need its own identity infrastructure, as our breakdown of Keycloak costs shows. A B2B MVP can be a narrowly scoped customer portal, for example: login, one self-service feature, and real data from the pilot customer.

Before you request a quote, answer three questions in writing. Which uncertainty is biggest: technology, usability, or willingness to pay? Who makes the final call, and based on what number? What happens if that number doesn't materialize?

With those answers, you'll know which of the four stages you're commissioning, and you can measure every quote against them. If the answer is an MVP, our MVP development page shows how we handle scope, fixed pricing, and expansion.

Prefer to talk it through? In a no-obligation 30-minute call, we'll assess your project together, even if it turns out a clickable mockup is all you need. Bring whatever you already have: sketches, a first draft, a list of potential pilot customers, or a letter of intent. That helps us see more quickly which stage is missing and which one you can skip.