[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"blog-post-poc-vs-prototype-vs-mvp":3,"blog-post-adjacent-poc-vs-prototype-vs-mvp":68},{"id":4,"title":5,"slug":6,"excerpt":7,"cover":8,"coverAlt":12,"datePublished":13,"dateModified":13,"category":14,"author":19,"tags":26,"answerFirst":31,"keyTakeaways":32,"body":38,"faqs":39,"sources":58,"relatedServices":59,"seo":63},"b8rtbzpy5mmv1o0qk82m2yhk","POC vs Prototype vs MVP: Which One Do You Need First?","poc-vs-prototype-vs-mvp","POC vs MVP vs prototype, explained by the question each one answers: feasibility, usability or demand. Who sees each, what it costs in time and risk, and which to build first.",{"url":9,"width":10,"height":11,"alt":12},"https:\u002F\u002Fmedia.drieverse.com\u002Fdrieverse-media\u002Fcms\u002Fpoc_vs_prototype_vs_mvp_cover_76b344030f.jpg",2400,1350,"Three equal spheres: a glass shell with a lit core, a panelled shell, a solid glow, under \"Three questions, not three sizes.\" Post on POC vs prototype vs MVP.","2026-10-20",{"name":15,"slug":16,"description":17,"seo":18},"Engineering","engineering","Software architecture, code quality and the engineering practice behind the systems we build.",null,{"name":20,"slug":21,"entityType":22,"role":23,"bio":24,"credentials":18,"photo":18,"profiles":25},"DrieVerse Tech","drieverse-tech","organization","Engineering Team","DrieVerse Tech is a software design and engineering studio. Case studies and posts published under this byline reflect the team's collective work, reviewed before publication.",[],[27,29],{"name":28,"slug":28},"decision-frameworks",{"name":30,"slug":30},"discovery","POC vs MVP comes down to the question each one answers. A proof of concept (POC) tests whether something can be built at all. A prototype tests whether people understand it and can use it. A minimum viable product (MVP) tests whether people will use it for real, in their own work. Build first whichever one answers the doubt most likely to end the project, and skip a stage only when its question is already answered.",[33,34,35,36,37],"A proof of concept tests whether something can be built, a prototype tests whether people understand it, and an MVP tests whether people will use it for real.","Build first whichever one answers the doubt most likely to end the project. Write that doubt as one sentence; it usually names the stage.","A prototype is allowed to be fake. An MVP is not: its data is real, its actions have consequences, and someone has to keep it running.","A pilot is not a fourth thing to build. It is a bounded first release of the MVP to a chosen group of users.","Say out loud which one you are building. Trouble starts when a prototype is presented as the product, or when POC code quietly becomes the foundation.","Three words get used for the first version of a product, often in the same meeting, and they mean different things. A proof of concept, a prototype and a minimum viable product each answer one question, and that question is what separates them, not their size or their polish. The short version of POC vs MVP: a POC tests whether something can be built, and an MVP tests whether anyone will use it once it is. A prototype sits between the two and tests whether people understand it.\n\nKnowing which question is still open tells you which one to build first, which one you can skip, and what you are allowed to keep afterwards.\n\n## POC vs MVP vs prototype: three questions, not three sizes\n\nA proof of concept proves feasibility, a prototype proves usability, and an MVP proves demand. They also differ in who sees them, what they are made of and what happens to them once their question is answered.\n\n| | Proof of concept (POC) | Prototype | MVP |\n|---|---|---|---|\n| The question it answers | Can this be built, with this data, at this scale? | Do people understand it, and can they get through it? | Will people use it, and keep using it, when nothing is staged? |\n| Who sees it | The team and the people funding the next step | Target users in a session, plus stakeholders | Real users, in their own work, unsupervised |\n| What it is made of | The one risky part, with nothing around it | Screens, flows and sample content, often with nothing behind them | A narrow working product with real data and support |\n| What it leaves behind | A yes or a no, and notes on how | A tested design and a clearer brief | A product to run, and evidence about demand |\n| Is it kept? | Rarely; the real version is built properly | The design, yes; the code, rarely | Yes; it is the first version of the product |\n| Done when | The risky part works, or clearly will not | Users finish the key tasks without help | Real use answers the question it was scoped for |\n\n## What a proof of concept proves\n\nA proof of concept proves that one specific technical risk can be overcome: an integration that may not expose the data you need, a model that may not be accurate enough on your documents, a volume of records that may be too slow to process. It answers a yes or no question, and it is built around that question alone.\n\nThat narrowness is the point. A good POC skips login, design, error handling and everything else a user would need, because none of it changes the answer. It is usually seen by the people deciding whether to fund the next step, and by nobody else.\n\nThe risk with a POC is proving the easy version. Testing an integration against a tidy sample instead of the messy records it will really receive gives a confident yes that falls apart later. Write down what would count as a no before you start, and test against the worst realistic input rather than the best.\n\n## What a prototype proves\n\nA prototype proves that people can understand and use the thing you intend to build. It is a model of the experience: screens, flows and enough content to make a task feel real, put in front of its future users so you can see where they hesitate.\n\nIt can be paper sketches, a clickable design file or a front end with nothing behind it. The right fidelity is the lowest one that still answers the question. Testing whether staff can find the approval step needs a clickable flow. Testing whether a manager trusts the figures on a dashboard needs realistic figures.\n\nIts risk is the opposite of a POC's. A polished prototype looks finished, and people who see it start to believe the product exists. Someone asks for a launch date, and the distance between a screen that looks right and a system that works drops out of the conversation.\n\n## What an MVP proves\n\nAn MVP, or minimum viable product, proves demand: that people will use the product for real, in their own work, and come back without being asked. It is the smallest version that does one job properly, with real data, real accounts and someone answering when it breaks.\n\n\"Minimum\" applies to scope, not to quality. An MVP can leave out most features, but the ones it has must work every time, because users who hit errors draw conclusions about the idea, not about the build. That is why it takes more than a prototype: it has to be secure, supported and maintained from the day the first person relies on it.\n\nThe usual MVP risk is scope. Every feature added to feel safer makes it slower to ship and harder to read. If usage is weak, you no longer know which part was the problem.\n\n## Is an MVP the same as a prototype?\n\nNo. A prototype is allowed to be fake: it can show screens with nothing behind them, because its job is to test understanding. An MVP is not allowed to be fake. The data is stored, the emails are sent, the payment goes through, and somebody is responsible for keeping it running.\n\nThe confusion is understandable, because tools that produce working screens in an afternoon have blurred the line. A prototype that happens to save data is still a prototype if nobody has checked how it handles security, backups, permissions, or two people editing the same record. The test is not whether it runs. It is whether you would let a customer depend on it.\n\n## Proof of concept vs pilot vs MVP\n\nA pilot is not a fourth thing to build. It is a way of releasing the MVP: a short, bounded release to a chosen group of users, with its questions written down before it starts. The proof of concept comes first and tests feasibility, the MVP is the product, and the pilot is that product's first controlled contact with real use.\n\nThe word causes trouble because some organisations say \"pilot\" when they mean trying a proof of concept in one department. If someone asks for a pilot, ask what will be in users' hands and for how long. If the answer is a working product in daily use, it is an MVP release, and our guide to [planning an MVP pilot](\u002Fblog\u002Fplanning-an-mvp-pilot) covers how to run one, from the questions to the decision at the end.\n\n## Which one do you need first?\n\nBuild first whichever one answers the doubt that would end the project soonest. Write that doubt down as a single sentence, and the sentence usually names the stage.\n\n- **\"We are not sure it can be done.\"** The data, the integration, the accuracy or the speed is in question. Start with a proof of concept.\n- **\"We are not sure people will understand it.\"** It is a new workflow, a change to how a team works, or an unfamiliar interface. Start with a prototype.\n- **\"We are not sure anyone wants it enough to change what they do today.\"** Start with an MVP, because only real use answers that.\n\nIf two sentences ring true, take them in that order. There is little point testing whether people want something that cannot be built, and little point building something people cannot use. When the only technical doubt is one integration, a small POC on that integration can run alongside a prototype of the workflow, and both answers arrive together.\n\n## When to skip a stage\n\nSkip a stage when its question is already answered, never because skipping looks cheaper. A proof of concept adds nothing when the technology is well understood: forms, records, reports and standard payment or email services rarely need proving. A prototype adds less when the product mirrors a workflow people already follow, such as moving a paper or spreadsheet process into a system that works the same way.\n\nThe stage you should almost never skip is the one your riskiest sentence points at. The prototype is the one teams skip most often, because screens feel like a detail, and then they find during the MVP that users do not follow the flow. At that point, changing it means changing working code, stored data and tests, not a design file.\n\n## What each stage costs in time and risk\n\nEach stage costs more than the one before, because each one needs more of the product to be real. A proof of concept is built around one question and can stop the moment it is answered. A prototype needs the whole journey thought through but nothing behind it. An MVP needs everything a user touches to work, plus the parts they never see: hosting, accounts, backups, monitoring and support.\n\nThe risk runs the other way. A failed POC costs little, because failing early is what it is for. A wrong prototype is a design that is still cheap to change. A failed MVP costs the most, in time and in the team's belief in the idea, so it should rest on the answers the earlier stages produced rather than on hope. How long each one takes depends on the scope you give it, which is why a clear question matters more than a fixed schedule.\n\n## How long to build an MVP: what sets the timeline\n\nHow long it takes to build an MVP depends on scope decisions more than on code. What stretches it is predictable: the number of user roles, each with its own screens and permissions; integrations with other systems, especially ones nobody has tested; data and content that has to be prepared; and decisions waiting on people who are not in the room.\n\nThe surest way to shorten it is to cut, before the build starts, everything that does not help answer the question the MVP exists for. A dependable estimate comes from a written scope, not a feature list, and a team that has run a POC or a prototype first can usually give a firmer one, because the biggest unknowns are already settled. For founders planning a first product, our [startup acceleration](\u002Fsolutions\u002Fstartup-acceleration) work starts from the same question.\n\n## Say which one you are building\n\nMost first versions are prototypes, and that is fine as long as everyone knows it. The trouble starts when a prototype is shown to customers or investors as the product, or when POC code becomes the foundation of the real system because it already works.\n\nAgree the label out loud before you start. This is a POC, and it will be thrown away. This is a prototype: the design stays, the code may not. This is an MVP, and it will be supported. The label sets what everyone expects of it, from the team to the people who see the demo, and it decides what is allowed to carry on into the next stage.\n\nIf you are deciding what your first version should be, or you have something built and are not sure which of the three it really is, discuss your first release with us. Working out which question to answer first is where our [custom software development](\u002Fservices\u002Fsoftware-development) projects begin.",[40,43,46,49,52,55],{"question":41,"answer":42},"What is the difference between a POC and an MVP?","A POC, or proof of concept, tests whether one technical risk can be overcome, such as an integration or the accuracy of a model, and is usually seen only by the team. An MVP, or minimum viable product, is a working product released to real users to test whether they will use it. A POC is normally thrown away; an MVP is the first version of the product and is supported from the start.",{"question":44,"answer":45},"What is the difference between a proof of concept and a prototype?","A proof of concept tests whether something can be built and ignores how it looks. A prototype tests whether people understand and can use the intended experience, and often has nothing working behind its screens. One answers a technical question for the team; the other answers a usability question with the people who will use the product. Many projects need both, sometimes at the same time.",{"question":47,"answer":48},"Is an MVP the same as a prototype?","No. A prototype can be partly or entirely fake, because its job is to test whether people understand the design. An MVP must really work: data is stored, actions have consequences, and someone is responsible for security, backups and support. A prototype that happens to save data is still a prototype until it is ready for a customer to depend on.",{"question":50,"answer":51},"What is the difference between a proof of concept, a pilot and an MVP?","A proof of concept tests feasibility before the product exists. An MVP is the smallest working version of the product. A pilot is a way of releasing that MVP: a bounded run with a chosen group of users and questions written down in advance, before a wider launch. Some organisations call a departmental trial of a proof of concept a pilot, so ask what users will actually have in hand.",{"question":53,"answer":54},"Do you need a proof of concept before an MVP?","Only if there is a technical doubt that could end the project, such as whether an integration exposes the data you need or whether a process can run fast enough at real volumes. If the product uses well understood technology, a POC adds little, and the time is better spent on a prototype or on the MVP itself. Skip a stage only when its question is already answered.",{"question":56,"answer":57},"How long should an MVP take to build?","It depends on scope decisions more than on code. The number of user roles, the integrations with other systems, the data and content to prepare, and how quickly decisions are made all set the timeline. A dependable estimate comes from a written scope rather than a feature list, and it gets firmer once a proof of concept or a prototype has settled the biggest unknowns.",[],[60,61,62],"software-development","app-development","it-consulting",{"metaTitle":64,"metaDescription":65,"ogImage":66,"canonicalPath":18,"noindex":67},"POC vs MVP vs Prototype: Which Do You Need First?","POC vs MVP vs prototype: what each one proves, who sees it, what it costs in time and risk, when to skip a stage, and which one to build first.",{"url":9,"width":10,"height":11,"alt":12},false,{"prev":69,"next":84},{"id":70,"title":71,"slug":72,"excerpt":73,"cover":74,"coverAlt":76,"datePublished":77,"dateModified":77,"category":78,"author":79,"tags":80},"nsn7l26hs2im1bhx17t5xvf0","Customer Onboarding for a New App: Design the First Useful Action","customer-onboarding-for-a-new-app","How to design customer onboarding for a new app around one useful action: what sign-up should ask, the first task, support, accessibility, the events to track and when to ask for feedback.",{"url":75,"width":10,"height":11,"alt":18},"https:\u002F\u002Fmedia.drieverse.com\u002Fdrieverse-media\u002Fcms\u002Fdays_day_29_export_blog_16x9_6aeb67f99f.jpg","Cover reading \"Let them achieve something first.\" as a lit path runs through a field of light to one bright square, beside five onboarding stages.","2026-10-17",{"name":15,"slug":16},{"name":20,"slug":21},[81,83],{"name":82,"slug":82},"process-design",{"name":28,"slug":28},{"id":85,"title":86,"slug":87,"excerpt":88,"cover":89,"coverAlt":91,"datePublished":92,"dateModified":92,"category":93,"author":94,"tags":95},"oio61h6nw64t16c23re3diqb","How Long Does It Take to Build an App? What Actually Sets the Timeline","how-long-does-it-take-to-build-an-app","How long does it take to build an app? What sets the timeline in each phase, what stretches it, what AI tools shorten, and how to get an estimate you can plan around.",{"url":90,"width":10,"height":11,"alt":91},"https:\u002F\u002Fmedia.drieverse.com\u002Fdrieverse-media\u002Fcms\u002Fhow_long_does_it_take_to_build_an_app_cover_9a712e7847.jpg","Toppled glass tiles stop at standing ones under the words Timelines slip on decisions, not code: what really sets how long an app takes to build.","2026-10-22",{"name":15,"slug":16},{"name":20,"slug":21},[96,97,98],{"name":82,"slug":82},{"name":28,"slug":28},{"name":30,"slug":30}]