# MVP, prototype or proof of concept: which one to build first > A proof of concept, a prototype and an MVP answer three different questions. Knowing which question you face tells you what to build, how much to spend and what comes next. Ilya Ismatov · CTO · 21 September 2026 · Product Bitmason: https://bitmason.dev/en/blog/mvp-prototype-proof-of-concept/ Founders often use "MVP", "prototype" and "proof of concept" as if they were three sizes of the same thing. They are not. Each one exists to answer a different question, and each one is built differently because of it. Pick the wrong one and you either spend months building something that cannot answer your question, or you answer a question nobody was asking. The simplest way to keep them apart is to name the question first and let the question choose the tool. ## Three questions, three tools Every new product carries three kinds of risk: - **Technical risk.** Can this be built at all, with the data, integrations and performance it needs? - **Usability risk.** Will people understand what the product is and how to use it? - **Market risk.** Will people actually use it, come back, and pay? A proof of concept deals with the first. A prototype deals with the second. An MVP deals with the third. Everything else follows from that: who sees the work, how polished it needs to be, how much effort it takes and what you do with it afterwards. ## Proof of concept: can it be done A proof of concept is a small technical experiment. It exists to show that one specific, uncertain thing works. Can a model extract the fields you need from scanned invoices with acceptable accuracy? Can the legacy system's API return the data fast enough for a live dashboard? Can two hardware devices talk over the protocol the vendor claims to support? A good proof of concept has these traits: - It targets one question, stated in writing before work starts, with a pass mark agreed in advance. - It ignores everything that is not that question. No sign-in, no styling, no error handling beyond what the test needs. - Its audience is the team, and sometimes a technical adviser or an investor's due diligence. - It is thrown away, or at most mined for a few useful pieces of code. In effort, a proof of concept is usually the cheapest of the three: one or two engineers for days or a few weeks. The main cost is discipline. The temptation is to keep adding features once the core idea works, and at that point the experiment has quietly become an unplanned product with none of the structure a product needs. If nothing about your product is technically uncertain (a booking tool, a marketplace, a CRM for a niche) you can skip this step entirely. ## Prototype: will people understand it A prototype is a model of the product that people can look at and click through. It tests whether the idea makes sense to the people it is for: whether they understand the offer, find their way through the main flow and recognise their own problem in it. Prototypes range widely in fidelity: - Paper sketches or wireframes, to agree the structure and the order of screens. - Clickable design mock-ups, to test the flow with real users in short sessions. - A coded front end with fake data, when the interaction itself is the question (a complex editor, a drag-and-drop planner). Most of the value comes from watching five or six target users try to complete a task with it. Where they hesitate, misread a label or give up, the design changes, and it changes cheaply, because nothing behind the screens exists yet. A prototype is also a strong tool for alignment. Co-founders, investors and the future engineering team all see the same thing, which removes a lot of the ambiguity that a written specification leaves behind. What a prototype cannot tell you is whether people will use the product in their real lives. People are polite in testing sessions. Clicking through a mock-up costs them nothing. That gap is what the MVP is for. ## MVP: will people use it, and pay A minimum viable product is the smallest real product that real users can use for a real job. It stores real data, runs in production and can take money if the model calls for it. Its purpose is to test the assumption most likely to sink the business, usually about demand or willingness to pay, with behaviour rather than opinion. The words that matter are "smallest" and "real": - **Smallest** means the product does one core job and little else. Every feature that does not help test the key assumption waits. - **Real** means users rely on it. It needs working sign-in, a sensible data model, basic security, error tracking and a way to measure what people do. Cutting these does not make an MVP leaner, it makes its results unreliable. An MVP is the most expensive of the three because it is production software: typically a small team over a few months rather than weeks. It is also the only one of the three whose code is meant to survive, at least in part. That is why the architecture decisions made here (the data model, the tenancy model, the hosting setup) deserve more care than anything in a prototype. An MVP does not have to be an app. For some ideas the smallest real product is a landing page with a waiting list, a manual service run behind a simple form, or a no-code tool. If that answers the question, it is the right MVP. ## Choosing where to start Start with the risk you understand least. - If you are not sure the core technology works, start with a proof of concept. Everything else is wasted if the answer is no. - If the technology is ordinary but the product is new to its users, start with a prototype. It is far cheaper to fix a confusing flow on a mock-up than in code. - If the product is well understood and the open question is whether the market wants it, go to an MVP, and keep it small enough that a negative answer does not end the company. Two signs you are building the wrong thing. First, you cannot state in one sentence what you will learn from it. Second, the scope keeps growing because "users will expect it". Both mean the work has drifted away from its question. ## How the three chain together When all three risks are present, they tend to run in order, and each one feeds the next: 1. The proof of concept settles the technical approach and hands the MVP team a design they trust, along with the limits they must respect. 2. The prototype settles the core flow and the vocabulary of the product, so the MVP team builds screens that have already been tested. 3. The MVP puts the result in front of real users and measures what they do. The stages can overlap. A designer can start prototyping while an engineer runs the proof of concept, as long as the prototype does not promise something the experiment later rules out. What should not overlap is the decision to build the MVP and the evidence that it is worth building. Keep each stage honest about what it proved and what it did not, and write that down, so the next stage does not rest on an assumption someone only hoped was tested. ## The short version - A proof of concept asks whether it can be built. It is small, technical and disposable. - A prototype asks whether people understand it. It is visual, cheap to change and shown to users. - An MVP asks whether people will use it and pay. It is real software with real users, and part of it will live on. - Start with the risk you know least about, and state the question before you build anything. If you have an idea and are not sure which of the three it needs first, that is a question worth settling before any budget is spent, and it is the question we start with when we scope an MVP. ## Questions about this article ### Can a prototype be turned into the MVP? Rarely as it stands. A prototype is built to be shown, not to hold real data or real users. Keep the design decisions and the lessons, and expect to rebuild the working parts properly. ### Does a proof of concept need a designer? Usually not. A proof of concept answers a technical question, so its audience is the team and perhaps a technical adviser. Plain screens or a script are enough. ### Is a no-code product a real MVP? It can be. If a no-code tool lets real users do the core job and gives you a clear answer about your riskiest assumption, it has done what an MVP is for. Plan the rebuild once the answer is in. ### Do we need all three before building the full product? No. Many products skip the proof of concept because nothing about them is technically uncertain. Build only the stages whose questions you cannot already answer.