PrototypeMVPMethodRequirements
Prototype vs MVP vs POC: what is the difference?
6 min read
A mock-up shows what an application will look like, a prototype shows how it will be used, a proof of concept (POC) shows that one technical problem can be solved, and a minimum viable product (MVP) tests with real users whether the product meets a need. They answer different questions, cost different amounts and end up in different places: only the MVP and version 1 are built to run in production.
Mixing them up is one of the most common sources of misunderstanding between a buyer and a software provider. Here are the definitions side by side, what each one proves, and how to sequence them for your project.
The definitions, side by side
| Deliverable | The question it answers | What it is | Does it work? | What it becomes |
|---|---|---|---|---|
| Wireframe | What is on each screen? | A grey-box layout, no styling | No | A basis for the mock-up or prototype |
| Mock-up | What will the app look like? | Designed screens with colours and typography | No, static images | The visual reference |
| Clickable prototype | How is it used, from start to finish? | Screens linked into journeys, with realistic data | Only on the surface | The specification for development |
| Proof of concept | Is this technical point feasible? | Throwaway code focused on one difficulty | Yes, on that one point | A lesson, rarely reusable code |
| MVP | Do real users get value from it? | A product reduced to one complete journey | Yes, in production | The foundation of version 1 |
| Version 1 | Does it serve its whole audience over time? | The complete first release | Yes, in production | The base for future releases |
Two columns deserve attention. "Does it work?" separates what you can show from what you can run. "What it becomes" tells you what you are really paying for at each stage.
Wireframes and mock-ups: the look
A wireframe sets the structure: which areas, which fields, which buttons, with no visual choices. A mock-up dresses that structure with colours, typography, icons and the final look of each screen. Both are pictures. You can click through a mock-up in a design tool, but nothing happens: no data changes, no rule applies.
For business software, their limit is that they mostly answer a question of taste. Yet what makes an internal tool succeed or fail is rarely the colour palette. It is the order of data entry, the exceptions, and the number of clicks needed for the task someone repeats fifty times a day.
The clickable prototype: the flow
A clickable prototype links the screens the way the final application will, with data that looks like the company's own: real product names, plausible amounts, actual statuses. You can walk through a whole journey, for instance from creating an order to invoicing it.
This is the stage where users finally say "no, that is not how we do it". Those corrections cost almost nothing on a prototype and a great deal once the code exists. It is also what makes a firm price possible: what is on screen is in the price, and anything else is an explicit decision, as explained in our article on fixed price versus time and materials.
A prototype, however, has no real business rules, no database and no security. It demonstrates; it does not produce anything.
The proof of concept: technical feasibility
A proof of concept answers one technical question before the budget is committed. Can we read this supplier's PDF invoices automatically? Can we write to this old ERP that has no documented API? Does the response time stay acceptable with the real volume of data?
It is deliberately rough: no polished interface, no error handling, no tests. It is judged on one answer, yes or no, with its conditions. Most projects do not need one. A proof of concept is only worth it when a specific technical point threatens the whole project, and connections to existing systems are the usual suspect.
The MVP: value, with real users
The MVP is the first deliverable that works for real: real users, real data, in production. It is cut down to one complete journey, because its job is to test an assumption (customers will pay, the team will adopt it), not to cover everything. How to decide what goes in is covered in our guide to MVP development.
Because it runs in production, an MVP must be secured, backed up and maintained. What gets reduced is the number of features, not the quality.
In which order, and which ones to skip
No project needs all six. The right sequence depends on what is uncertain:
| Your situation | A sensible sequence |
|---|---|
| Internal tool, well-understood need, no technical risk | Prototype, then version 1 delivered in stages |
| New SaaS product, market still to prove | Prototype, then MVP, then version 1 |
| Risky connection to an existing system | Proof of concept alongside the prototype, then version 1 |
| Brand identity to create from scratch | Mock-up work folded into the prototype |
The prototype appears on every line, and not by accident: it is the cheapest way to get everyone to agree on what will be built.
The mix-ups that cost money
Taking the prototype for an almost finished app. The screens exist, so "the hard part is done". In reality the business rules, data, integrations and security are all still to be built. A good prototype shortens a project; it does not replace it.
Putting a proof of concept into production. Its code was written to answer a question quickly, not to last. Promoting it to a product means inheriting technical debt on day one.
Approving mock-ups without the journey. Beautiful screens, signed off one by one, can hide an absurd sequence that only shows up during development.
Calling a full version 1 an MVP. An MVP that contains everything costs as much as a version 1 and teaches you nothing more.
Who owns what
Ask the question at every stage, before work starts. At LPR Studio, the demonstration prototype is free: it is presented in a video call, not delivered, and it remains the property of the studio. For the application built afterwards, the rights depend on the chosen model and are defined case by case in the contract; the three models are described on our offers page.
Where to start
If you are not sure which deliverable you need, start with the one that costs the least and clarifies all the others: the prototype. At LPR Studio it is free and presented in a video call within 5 working days, with screens, user journeys and realistic data. Once validated, it becomes the specification, and the fixed price is set before the first line of code. The full process is on our approach page.