Building apps
What is a proof of concept (POC)?
A proof of concept (POC) is a small build made to answer one question: is this possible at all? It tests feasibility rather than desirability or usability.
New to Bolt? Sign up free.
Technical definition
A proof of concept is a narrowly scoped implementation demonstrating that a specific technical approach works. It targets the single riskiest unknown in a plan and is discarded once that unknown is resolved.
The three early-stage artifacts answer different questions:
- Proof of concept: can this be done?
- Prototype: how should it work and feel?
- Minimum viable product: does anyone want it?
They are sequential only when the technical risk is real. Most business software has none, and a POC would be a step that answers nothing.
In plain terms
A proof of concept tests the part you are not sure is possible.
If the whole idea depends on being able to read data out of a system nobody has an integration for, build only that. Nothing else matters until it works.
Why it matters
The value of a POC is that it fails cheaply. Finding out in week one that the integration you depended on does not exist is a good outcome. Finding out in month four, after building everything around it, is not.
The mistake is building one when there is nothing to prove. A booking system, a client portal, or a CRM has no meaningful technical risk, so a POC for one just delays the useful work. Ask what you are unsure is possible. If the honest answer is nothing, skip straight to a prototype or an MVP.
The other trap is the POC that turns into the product. It was built to answer a question, with no error handling, no security, and no structure. When it works and gets promoted into production, all of that debt ships with it.
Decide out loud which of the three you are making, and if a POC succeeds, rebuild it rather than extending it.
