Glossary

What Is a Proof of Concept?

Updated November 13, 2026 · Team Fonda

Short answer

A proof of concept (POC) is a small, quick test that shows whether a key part of your idea can work in practice. It is not a product and customers rarely see it. Its only job is to answer one yes-or-no question before you spend real money.

Key takeaways

A proof of concept answers "can this work?", not "will people buy it?".
Test only the riskiest part of the idea, with a pass mark you set in advance.
It comes before a prototype and an MVP, and you throw it away afterwards.
Many simple businesses do not need one. You need it when something about the idea is unproven.

What a proof of concept means in plain words

Some ideas rest on a step nobody is sure about. Can software read a blurry receipt accurately? Will a cake survive two days in the post? Will a supplier sell to you in small batches at a price that leaves a margin? A proof of concept is the smallest experiment that settles that one doubt.

The doubt is not always technical. For a service business it might be operational (can one person clean four flats in a day?) or commercial (will a landlord agree to a pop-up lease?). What makes it a proof of concept is that it tests feasibility, meaning whether the thing can be done at all.

Proof of concept vs prototype vs MVP

These three terms get mixed up because they all come early. They answer different questions.

	Question it answers	Who sees it	What happens to it
Proof of concept	Can this work?	You and your team	Thrown away
Prototype	What should it look and feel like?	A few test users	Revised, then replaced
MVP	Will people use and pay for it?	Real customers	Improved over time

A proof of concept says nothing about demand. An idea can be perfectly possible and still unwanted, which is why you also need idea validation with real customers.

How to run a proof of concept

Name the riskiest assumption. Write one sentence: "This business only works if...". If nothing in that sentence is in doubt, skip the proof of concept.
Set the pass mark before you start. A number or a clear yes-or-no result, so you cannot talk yourself into a pass later.
Build the least you can. Use existing tools, a spreadsheet, a manual process or a rough sample. Ignore design, sign-up and anything not under test.
Put a limit on time and money. Days or a couple of weeks, not months.
Record the result and decide. Go ahead, change the approach, or stop.

Tip

If the test takes longer than a few weeks, you are probably building a product, not proving a concept. Cut the scope until only the doubt remains.

A worked example

This is an illustration with made-up numbers. Say you want to build an app that lets market stall owners photograph paper receipts and get their expenses sorted into categories. The whole idea depends on the software reading messy receipts correctly.

Assumption: an off-the-shelf text recognition service can read real receipts well enough.
Pass mark: at least 90 percent of receipts read with the right total and date.
Test: you collect 200 real receipts from three stall owners and run them through the service using a short script. No app, no accounts, no design.
Result: 172 of 200 are read correctly, which is 86 percent. Most failures are faded thermal paper.
Decision: not a pass yet. You try asking users to retake faded photos, rerun the failed receipts and reach the pass mark. Now it is worth designing a prototype.

The test cost a few days. Finding the same problem after building the full app would have cost months of runway.

Why it matters for a first-time founder

You meet this term after you have chosen an idea and seen signs of problem-solution fit, and before you commit to building. It protects you from the most expensive kind of surprise: discovering late that the core of the business cannot be done at a workable cost.

Investors and partners may also ask for one. If you are raising money for something technical, a working proof of concept shows the main risk has been dealt with. In Fonda's journey, the Key risks step in the Validate phase is a natural point to ask which assumptions could sink the idea and whether one of them needs a proof of concept. The guide on how to build an MVP covers what comes next.

Common mistakes

Testing the easy part. A proof of concept that confirms something you already knew proves nothing.
Polishing it. Time spent on looks is wasted on something you will throw away.
No pass mark. Without one, every result looks encouraging.
Treating it as proof of demand. It shows the idea can work, not that anyone wants it.
Turning it into the product. Code and processes built in a hurry make a weak foundation. Start the real build fresh.

Frequently asked questions

Does every startup need a proof of concept?

No. If your business uses known methods, such as a cleaning service or an online shop on a standard platform, there is little feasibility risk to test. Spend the time on customer demand instead. A proof of concept is useful when a technical, operational or supply question is unanswered.

How long should a proof of concept take?

As short as possible. Most can be done in days or a few weeks, because they test one thing. If yours is growing beyond that, narrow the question.

What is the difference between a proof of concept and a pilot?

A proof of concept tests whether something can work, usually in private. A pilot is a small real-world run of a working product or service with actual customers, to see how it performs before a wider launch.

What should a proof of concept document include?

Keep it to one page: the assumption you tested, the pass mark, how you tested it, the result, what you learned and what you will do next. That is enough for a co-founder, partner or investor to follow your reasoning.