A proof of concept (PoC) tests whether a specific technical approach can work. A prototype models a proposed solution so you can evaluate how people use it. A minimum viable product (MVP) is a minimal offering used to learn from customer behavior. In software, an MVP might be a small working app or a service delivered partly by people. Each approach answers a different question. The right choice depends on what you need to learn before committing more time and money; you do not have to build all three.
A working integration does not establish customer demand. A successful prototype task does not establish repeat use. The next test should address whichever question still affects your decision.
PoC, prototype, and MVP compared
These are typical uses in software projects. One model can support more than one test, but the results answer different questions.
| Question | Proof of concept | Prototype | Minimum viable product |
|---|---|---|---|
| Main question | Can this approach meet a specific requirement? | Can people understand and complete the intended task? | How do customers respond to the offer? |
| Typical output | A focused technical test and its results | Paper screens, a clickable design, or a coded model | A minimal offering, delivered manually, automatically, or through a mix of both |
| Who takes part | People who can assess the technical result | Intended users and the team evaluating the design | Customers or users from the intended audience |
| Evidence collected | Results against agreed data, speed, or access requirements | Task attempts, misunderstandings, and interaction problems | Actions relevant to the question, such as use, return visits, or purchase |
| What it does not prove | Customer demand or readiness of the whole product | Retention or willingness to pay from a successful task test alone | A sustainable business or product-market fit from one early test |
| A useful result | Whether the tested requirements are met and what remains uncertain | Which parts of the tested flow need to change | Whether customer behavior supports the business assumption |
| When another test may come first | The relevant technical question is already answered | The interaction risk is already well understood | A simpler discovery step can answer the immediate question |
What is a proof of concept?
In software development, a PoC tests a specific technical assumption: something the team believes can work but has not yet established. It might concern an integration, performance, or access to data. The PoC investigates that question rather than creating a finished product.
A useful test starts with clear requirements. In its migration guidance, AWS recommends defining entry and exit criteria for a PoC, including functionality, performance, and security requirements. These criteria give the team a basis for judging the result.
A successful PoC provides evidence that the approach meets the tested requirements under the tested conditions. It does not establish that the whole application is ready or that customers want it. If documentation or a previous implementation already answers the relevant question, a separate PoC may add little value.
What is a prototype?
A prototype is a model of a proposed solution used to evaluate its design or function. Here, we focus on UX prototypes: models that let people try a proposed interface or workflow before the team commits to implementing it in full. They can be paper screens, clickable designs, or small coded versions.
Testing with the intended audience can reveal problems the team has missed: where people become confused or cannot complete a task. Whether the model contains code is a separate issue; code alone does not make it an MVP.
NN/g explains that prototypes vary in detail and interactivity and that their form should suit the test. A rough sketch may be enough to explore a layout. A more detailed, interactive model may be needed to test a complete task. Greater visual polish does not, by itself, provide stronger evidence of customer demand.
What is an MVP?
An MVP tests a business assumption through customer behavior. The question might be whether people use a service, return when they need it again, or pay for an offer. The Lean Startup places the MVP within a build, measure, learn loop: the results inform what the team does next.
An MVP may be a usable first software release, but fewer features are not enough to define its purpose. The team still needs a clear question and a way to observe behavior that answers it. A prototype or demo can also support an early demand experiment if customers can take a meaningful action in response to a clearly described offer.
The delivery does not have to be fully automated. Agile Alliance includes manual services among the possible forms of an MVP. What matters is that the offering supports the test and delivers what participants have been promised. A broken core workflow can distort the result: people may abandon the service because it fails, rather than because they do not want it.
The differences between each pair
Consider a hypothetical B2B service company whose clients email requests and then ask for progress updates. The company wants a portal for submitting requests and checking their status, connected to its existing work-management system.
Each comparison separates a different pair of unanswered questions.
| Comparison | What each one tests (hypothetical portal example) |
|---|---|
| PoC vs prototype | A PoC checks whether a technical approach can meet a requirement. A prototype evaluates the proposed experience. For the portal, a PoC might test access to status data in the existing system, while a prototype lets clients try the submission and status screens. One coded model could support both tests, but a working integration and a clear interface are separate findings. |
| PoC vs MVP | A PoC tests whether the approach works under specified conditions. An MVP tests how customers respond to the offering. Even if the portal can retrieve every required status update, clients might continue using email. The integration result answers a technical question; it does not answer the adoption question. |
| Prototype vs MVP | A prototype walkthrough can reveal whether clients understand the portal. An MVP experiment can test whether they choose it for actual requests. The prototype might also support an earlier demand test, such as inviting clients to apply for a clearly described pilot. Each result has limits: completing a simulated task, applying for a pilot, and returning to a live service are different kinds of evidence. |
One product idea, three different tests
Here is how each test could work for the portal. This is a fictional planning example, not a client case. The sequence is illustrative; tests could start elsewhere or run in parallel.
PoC: test the uncertain integration
Assumption: the company's account with its work-management provider allows access to the custom status fields the portal needs. Status changes can also be retrieved or received within the delay the workflow can tolerate.
Why it is unknown: in this example, reviewing the documentation and account configuration has not resolved those questions. If that review had provided a reliable answer, a separate PoC might not be necessary.
Test: a focused integration test using authorized test accounts and representative records. The team records available fields, update delays, and relevant permission and failure cases. It compares results with agreed requirements and notes differences between test and production conditions.
Evidence: whether the required fields and updates are available within those limits. One successful API response is not enough to establish that the planned integration will work.
Next decision: continue if the approach meets the tested requirements. If it fails, distinguish a fixable implementation problem from a limitation of the integration before changing the approach or the product promise. If the environment cannot answer the production question, the result remains inconclusive.
Limit: the test does not establish that clients want the portal or that the entire production system is ready.
Prototype: test the request flow
Assumption: a client can submit a request and find its status without someone explaining the interface.
Test: a model of the submission, confirmation, and status screens. It could be a clickable design or a small coded version with test data. Participants attempt the task using sample requests, so the company is not yet processing real work through the model.
Evidence: where participants hesitate, misunderstand a status label, lose their place, or need help. Their attempts reveal more about the flow than comments about whether the screens look attractive.
Next decision: revise confusing steps and test them again, or move forward when the tested flow is clear enough for its intended use.
Limit: a smooth walkthrough does not establish that clients will use the portal for real work, return to it, or pay for it.
MVP: test adoption of the portal
Assumption: invited clients will use the portal for actual requests and return to check progress when they need an update, rather than relying on email for the same task.
Test: a limited portal where clients submit requests, view their own saved requests, and see the current status. The service team receives and processes those requests. Access controls keep each client's records separate. Some status updates can be entered manually while the company tests adoption, with clear expectations about how the service operates.
Evidence: actual submissions, return visits when updates are relevant, continued use of email, abandonment, and the help clients need. The observation period reflects how frequently clients make requests; a signup alone does not establish adoption.
Next decision: if clients adopt the workflow, decide which improvements or automation matter next. If they do not, investigate the offer, onboarding, reliability, audience, and request frequency before changing or stopping the idea. If the question is willingness to pay, usage data alone is insufficient; the test needs to observe purchasing behavior.
Limit: the findings concern this offer and these participants under specific conditions. They do not establish product-market fit, scalability, or long-term demand.
A manual alternative
There may be an earlier question: do clients value a clearer request-and-status service at all? The company could test that by accepting requests through a basic form and delivering status updates manually, before building a self-service portal.
That tests demand for a narrower service, leaving the portal's interface and integration untested. It may be the right next step if the immediate decision is whether to offer the service at all.
Which one should you build first?
A team confident in its integration might begin with a prototype. A team with little evidence of demand might first test a manual service. The starting point is an assumption whose failure would substantially change the next decision. Both uncertainty and the cost of being wrong matter.
An unresolved technical requirement: a PoC can test whether the proposed approach meets it.
An unclear interface or workflow: a prototype can show where intended users struggle.
An unanswered business question: an MVP experiment can test customer behavior relevant to that question.
If the problem or intended audience is still poorly understood, discovery may come before any of these. There is no need to build a substantial application just to call it an MVP.
These tests remain useful after launch: a team can prototype a new feature or run a PoC for another integration. An unanswered question can arise at any stage.
When a test fails, the first question is whether it was capable of producing a reliable answer. A technical failure may need an implementation fix rather than a new approach. A usability problem may need a revised flow. Weak business results may reflect the audience, offer, onboarding, or reliability. Those possibilities need examination before one result is treated as proof that there is no market.
Write the next test before you build
A short written plan connects the test to the decision it should inform:
Decision: what will we decide after this test?
Assumption: what must be true for that decision to make sense?
Test: what is the smallest model, technical experiment, or offer that can test it?
Participants and conditions: who needs to take part, and what conditions matter?
Evidence: what actions or results will we observe?
Criteria: what would lead us to continue, change, stop, or call the result inconclusive?
Limits: what will this test leave unanswered?
The last question is as useful as the first. It prevents a result about one aspect of the product from being treated as approval to build everything else.
Mockup, demo, and pilot
Related terms describe a model's form, its presentation, or its testing conditions:
A mockup usually shows how something looks and can be part of a prototype. A demo shows a product or concept in action; what it reveals depends on the audience's response and what the team measures. A pilot is a limited trial in real operating conditions. It can test an MVP or an existing product, so it is not a mandatory stage after every MVP.
A minimum marketable product (MMP) emphasizes having an offer ready to sell. Learning and selling can happen together; the terms emphasize different goals.