MVP vs Proof of Concept: Which Does Your Startup Need?

• Match the build to your biggest unknown: technology risk points to a proof of concept, and demand or usability risk points to a prototype.
• Go straight to an MVP when the technology is proven, and you've talked to real users, ideally one who has agreed to pay.
• In B2B software, "viable" means a paying business can rely on the product for one real job from start to finish.
• Keep the lessons from a proof of concept even if you rewrite its code, because that code was written for speed.
• A straightforward MVP takes around 3 months, so be wary of fixed timelines quoted before the scope is clear.

A proof of concept is a small internal test that answers one technical question, usually with rough code that real users never see. The term has a formal place on NASA's Technology Readiness Level scale, a 9-step measure of a technology's maturity. NASA notes that "often during TRL 3, a proof-of-concept model is constructed," whereas a fully functional prototype is only achieved at TRL 6 [1].

Skipping that step costs money when the technology is uncertain. The US Government Accountability Office's Technology Readiness Assessment Guide puts it plainly: "technologies that are not adequately mature have led to program delays and cost increases" [2]. When founders ask me what a PoC actually involves, I tell them this:

I'll answer this without naming the client, but the pattern is the same every time. A proof of concept has to answer one technical question: whether the idea can work at all. It might be whether an AI model reaches the accuracy the product needs, whether a hardware or Qt/C++ integration behaves as promised, whether a third-party API's limits are workable, or whether performance holds up with real data volumes. If we can't state that question in one sentence, we aren't ready to start.

Most B2B software doesn't need a proof of concept at all, because a CRUD web app (one that mainly creates, reads, updates, and deletes records) built on Node.js, Django, or React runs on technology thousands of teams have already proven, so a PoC would only confirm what everyone knows.

A prototype is a model of how the product will look and flow, built so people can react to it before anyone writes production code, and it's usually the cheapest of the three builds to change. Kara Pernice of Nielsen Norman Group calls it "a hypothesis," a candidate design you test against a specific problem [3]. Her guide to prototype fidelity adds that with a low-fidelity version "you can make design changes more easily during the test," which is why we settle the expensive questions in Figma before anyone writes code:

We mainly build a clickable prototype in Figma, and our designer makes it. Before it goes to the client, the designer and a developer sit down and go through it together. The goal is to cut anything that looks great on screen but would take far more time to build than we planned, mostly advanced widgets and custom interactions. That way the client sees a prototype we can actually deliver, and nobody falls in love with a feature that blows up the schedule.

We usually show it to our client and/or the person responsible for making decisions.

The cost depends on what the client expects and how big the project is. A small product needs a simple prototype. A bigger project needs a much more complex one, which takes more time and more money up front. That investment is worth it because changing a screen in Figma costs a fraction of what it does in code.

If your biggest doubt is whether customers will understand the product, show the same clickable flow to a few people from your target market as well. View our UX Design Services Guide for more details.

An MVP is a real, working product with the smallest feature set that lets you learn from actual users. Frank Robinson of the product firm SyncDev first used the term in 2001 and later described it as a product "big enough to cause adoption, satisfaction and sales, but not so big as to be bloated and risky" [4]. SyncDev's current definition calls it "the unique product that maximizes return on risk for both the vendor and the customer" [5].

Eric Ries popularized the term through his blog, and later in his book The Lean Startup, and in his 2009 guide to the MVP, which defines it as the version that lets a team "collect the maximum amount of validated learning about customers with the least effort" [6]. Validated learning means evidence from what users actually do, such as signing up or paying, rather than what they say they'd do.

Founders fixate on "minimum," but in B2B software the word that decides whether an MVP works is "viable," and here's how I define it for the businesses we build for:

For a B2B product, viable means a paying business can use it to do one real job from start to finish and rely on it. That includes the basics, such as login, access rights, and data that doesn't get lost. If a company can't trust the product with its daily work, it isn't viable, however small it is. I would rather ship one feature that works reliably than five that don't.

Paul Graham's essay Do Things that Don't Scale argues that "it usually works best to get something in front of users as soon as it has a quantum of utility" [7], and for a B2B buyer that quantum is one job done reliably. Our guide to choosing an MVP development company covers who should build it, and our MVP Testing Guide covers how to learn from your first users.

When a founder says "I need an MVP," I ask one question. What is the one assumption that kills this if it's wrong, and is it about the technology or about the customer? If the risk is whether it can be built at this cost and with this accuracy, they need a proof of concept. If the risk is whether people will want it and pay for it, they need a prototype. If they can't name the assumption, they aren't ready for an MVP. They are ready for a conversation.

About six in ten requests should start with something smaller. Most founders say "MVP" and mean the whole product, only cheaper. The other four in ten can go straight to building because their technology is proven, they have talked to real users, and ideally someone has already agreed to pay.

The budget decides how big the product is, not whether it is the right one. A big budget doesn't make an unvalidated idea safe, and a small one doesn't make a validated idea unbuildable. I don't argue with a founder's vision. I ask which one user and which one problem we prove first. The vision tells us what to test, and the results tell us what to build.

Yes, I have talked people out of what they asked for. Most MVPs are too big. An MVP is the cheapest way to find out you're wrong. If you already know the answer, build; if you don't, test first.

Run through this table before you ask any agency for a quote.

Runway, the months of cash you have left before the money runs out, is the other reason to choose the smallest build that answers your risk. CB Insights' 2026 analysis of startup failures covered 431 VC-backed shutdowns, 385 of them with an identifiable cause [8]. Among those, 70% ran out of capital, and 43% had poor product-market fit, meaning too few customers needed what they had built. The report adds that running out of money is "almost always the final cause of death, not the root problem."

The most expensive mistake is building the full product before testing the one thing it can't work without. Name the assumption that kills the idea if it's wrong. If it's about technology, you need a proof of concept. If it's about the customer, you need a prototype. Once you know the answer, build the MVP.

Founders often ask me whether skipping that test has ever gone wrong on one of our own projects, so here's the clearest example I have, with the client kept anonymous:

Yes, it has happened. A client came to us wanting an MVP quick and cheap. In the first conversations, they never mentioned that the product depended on a map and location integration. That was the main feature, and it wasn't in the original scope.

It surfaced after we had agreed on the scope. The client then argued that this should be part of the standard functionality we were already building. It wasn't. Map and location integration is not a basic feature. It was the core of the product, and it needed its own time and budget. The project took longer than we planned.

We did what we could to keep the client happy and limit the loss. The real problem was that their expectations of an MVP were far too high for the business need and for the budget they had put into it.

The lesson is simple. Before we agree on any scope, I now ask what the product can't work without, and I make the client name it. If that one thing is a map, a hardware link, or a third-party API, it gets tested first, before we build anything around it.

A small proof of concept for the map integration, scoped and priced separately, would have surfaced that work while it was still cheap to plan for. That's how most B2B products should use a PoC: focus on the single feature everything else depends on, while the rest of the product waits for the MVP.

That depends on what the code was written to do. PoC code is usually written fast to answer one question, so shipping it as the product turns its shortcuts into technical debt, meaning work you pay for later when they need fixing. A Figma prototype leaves designs but no code behind, whereas MVP code is written to last because it becomes the product's foundation.

Reuse the lessons from your proof of concept, not necessarily the code. It was written to prove an idea quickly, and the product has to last.

If the PoC or the MVP succeeds and the client wants to continue, we reuse what we've built and expand it into a full product. If the client decides to stop after the MVP, we hand over the code under the agreement we set at the start, and we're happy to do it.

Before any work on a proof of concept starts, ask whoever builds it whether the code is meant to survive into the MVP or be rebuilt. Either answer can be right, but the choice changes how they write it and what you budget for next.

I don't give fixed timelines, and I'm wary of anyone who does. A proof of concept, a prototype, or an MVP can take anywhere from a few weeks to several months, and sometimes more than a year. It depends on the scope, the complexity of the integrations, how quickly we get the information we need, and how many rounds of feedback it takes. In a straightforward case, an MVP takes around three months.

Dates still matter. I always want a target for completion and delivery, because a project without one slips. We treat that date as a plan and adjust it as we learn new information.

An MVP normally takes about three months, but that depends on the client's expectations, how quickly we gather the information we need, and how few rounds of back-and-forth it takes. The team is small, usually two to four people.

There is no single language we use. First we check what we have to deliver, in what time frame, and on what budget. Then we discuss the technology with the client and pick what fits.

For what drives the budget at each stage, see our MVP Development Cost Guide. Scope drives the price, so settle it first, and be cautious of any fixed price that arrives before anyone has named your riskiest assumption.

Serious funders treat feasibility and demand as separate questions. SBIR stands for Small Business Innovation Research, and the US National Science Foundation's SBIR Phase I program offers "up to $305,000 in non-dilutive funding" over 6 to 18 months to "build your prototype or proof-of-concept" [9]. Phase II goes up to $1,250,000 over 24 months, and because the money is non-dilutive, you don't give up any equity to get it.

Match the evidence to the audience you're raising from: a PoC shows a technical funder the hard part works, while an MVP with paying users shows a market investor that people want it.

Is a proof of concept the same as a prototype?

No, they answer two different questions about your product. A proof of concept tests whether the technology can work, usually with rough code only your team sees. A prototype tests whether people understand and want the product, usually as clickable screens in a tool like Figma. On NASA's Technology Readiness Level scale, a proof-of-concept model often appears at TRL 3 and a fully functional prototype at TRL 6.

Do I need a PoC before an MVP?

Only when your idea carries genuine technical risk. If the product depends on something unproven, such as an AI model's accuracy or a hardware integration, test that first. If you're building a standard web app on proven technology and you've already talked to real users, you can usually go straight to an MVP.

Can a prototype become an MVP?

A clickable Figma prototype can't become the MVP directly. It contains no production code, so its screens and flows become the design the MVP is built from, which saves real time once development starts. A partly working front-end prototype can sometimes carry over, but only if it was built to production standards from the start.

How long does a proof of concept take?

It depends on the technical question it has to answer. A PoC, a prototype, or an MVP can take anywhere from a few weeks to several months, sometimes longer, depending on scope and how complex the integrations are. A narrow PoC is usually the quickest of the three.

Is a PoC or an MVP better for raising money?

That depends on the kind of funder you're talking to. Grant programs such as NSF SBIR Phase I explicitly fund prototype or proof-of-concept work, so feasibility evidence fits there. An investor judging market demand will want real users and, ideally, revenue, which only an MVP can show.

If you can name the one assumption that would sink your idea, you already know which build comes first, and if you can't, that's the conversation to have before anyone writes code.

1. NASA, "Technology Readiness Levels," published 27 September 2023, updated 25 June 2026. Supports the TRL scale, the TRL 3 proof-of-concept line, and TRL 6 prototype. https://www.nasa.gov/directorates/somd/space-communications-navigation-program/technology-readiness-levels/
2. US Government Accountability Office, "Technology Readiness Assessment Guide" (GAO-20-48G), 7 January 2020, reissued 11 February 2020. Supports the quote on immature technology causing delays and cost increases. https://www.gao.gov/products/gao-20-48g
3. Nielsen Norman Group, Kara Pernice, "UX Prototypes: Low Fidelity vs. High Fidelity," 18 December 2016. Supports "a prototype is a hypothesis" and easier changes during low-fidelity tests. https://www.nngroup.com/articles/ux-prototype-hi-lo-fidelity/
4. SKMurphy, "Frank Robinson's Minimum Viable Product Definition," 24 April 2017. Supports Robinson's first use of the term in 2001 (quoting SyncDev) and his 2008 definition. https://www.skmurphy.com/blog/2017/04/24/frank-robinsons-minimum-viable-product-definition/
5. SyncDev, "Minimum Viable Product," undated, accessed 19 October 2026. Supports SyncDev's current MVP definition. https://www.syncdev.com/minimum-viable-product/
6. Eric Ries, Startup Lessons Learned, "Minimum Viable Product: a guide," 3 August 2009. Supports the Ries MVP definition. https://www.startuplessonslearned.com/2009/08/minimum-viable-product-guide.html
7. Paul Graham, "Do Things that Don't Scale," July 2013. Supports the "quantum of utility" quote. https://paulgraham.com/ds.html
8. CB Insights, "The top 9 reasons startups fail," 5 March 2026. Supports 431 shutdowns, 385 with identifiable cause, 70% ran out of capital, 43% poor product-market fit, and the "final cause of death" quote. https://www.cbinsights.com/research/report/startup-failure-reasons-top/
9. US National Science Foundation, America's Seed Fund, "About NSF SBIR/STTR," accessed 19 October 2026. Supports Phase I (up to $305,000, 6 to 18 months, prototype or proof-of-concept) and Phase II (up to $1,250,000, 24 months). https://seedfund.nsf.gov/our-program/