A proof of concept SOP tests whether the hardest technical part of your product actually works, before you build everything around it. It takes two to six weeks and ends with a yes or no backed by numbers. A proof of concept answers "can it work?", and nothing else: no login, no design, no customers using it. Founders who skip this step build a polished app around an engine that fails on real data.

What is a proof of concept and when should you use it?

A proof of concept is a small, throwaway build that tests one technical assumption under realistic conditions. Kent Beck's Extreme Programming calls a short version of this a spike: a quick experiment that answers a technical question, after which the code gets thrown away. A proof of concept is a set of spikes with written pass criteria and a deadline.

It differs from its neighbours. A prototype tests whether people understand and want the product, which is the prototype testing SOP. A Wizard of Oz test fakes the technology with humans to test demand. A proof of concept tests the technology itself.

Use this SOP:

When your feasibility assessment flags a component below TRL 6, meaning it has not been shown to work in a realistic setting.
When the product promise depends on a number: accuracy, speed, cost per use, battery life, detection rate.
Before you raise money for a technical build, since investors ask what you have proven.
When two technical approaches compete and only data can settle it.

What do you need before you start?

The riskiest assumption, taken from the technical feasibility assessment SOP.
Realistic test data: real photos, real audio, real documents or real sensor readings from your target customers.
A builder: you, a technical co-founder or a contractor paid for a fixed scope.
A time and money cap you agree on before the work starts.
A place to log decisions and results daily, such as Notion or a GitHub README.

How do you run it, step by step?

1. Pick one assumption

Write the single technical assumption that kills the product if false: "Speech-to-text can turn a noisy voice note from a building site into correct invoice line items." If you have three risky assumptions, rank them and test the deadliest first. One proof of concept, one assumption.

2. Write pass criteria before building

Set numeric thresholds: accuracy, speed, cost per operation, the share of cases it must handle. Name the test set and the conditions. Written criteria stop the familiar end-of-project drift, where 78% suddenly becomes "good enough".

3. Cut everything that doesn't test the assumption

No screens beyond a script or a notebook, no login, no database design, no deployment pipeline. Use existing libraries and APIs wherever they exist. Set the deadline at 2 to 6 weeks; a proof of concept that takes three months has turned into a product build.

4. Collect realistic test data first

Gather the data before the build, and split it into a development set for building and a held-out set the builder never sees until the final test. Include the hard cases customers will throw at you: noise, bad lighting, typos, odd formats. Test data that is too clean gives a pass that collapses in the field.

5. Build in small spikes and log every day

Try the simplest approach first and measure it against the criteria on the development set. Log what you tried, what changed and the result each day. If the simplest approach passes, stop; extra cleverness belongs in the product build.

6. Run the final test on held-out data

Run the build once on the held-out set and record every metric against its threshold. Repeat runs where results vary (AI models, sensors) and report the range. Show the failures as well as the average, since failures show what the product will need around the engine.

7. Decide and document

Choose: proceed, proceed with a changed product design, try a second approach within a new cap, or stop. Write a one-page result memo with the criteria, the numbers, examples of failures and what to keep. Treat the code as disposable: keep the learnings and test data, rebuild the product properly.

Template you can copy

PROOF OF CONCEPT BRIEF

Assumption to test:
"We believe [technology/approach] can [do what] on [which data] under [conditions]."

Pass criteria (all must be met on held-out data)
| Metric              | Threshold | How measured |
| Accuracy / success  | ≥ ____%   |              |
| Speed               | ≤ ____ s  |              |
| Cost per operation  | ≤ $____   |              |
| Coverage of cases   | ≥ ____%   |              |

Test data: ____ examples, source ________
Development set: ____  Held-out set: ____ (builder has no access until final test)

Out of scope: UI, login, deployment, ________
Builder: ________  Deadline: ________  Budget cap: $________

DAILY LOG
Date | What I tried | Result on dev set | Next step

RESULT MEMO
Metric | Threshold | Result | Pass/Fail
Failures (examples): ________
Decision: proceed / proceed with design change / second approach / stop
Keep: test data, findings ________   Throw away: ________

Worked example: voice notes into invoices for tradespeople

This is an illustrative case with invented numbers. A founder wants electricians and plumbers to dictate a voice note after a job and get a ready invoice. The assumption: speech-to-text plus a language model can extract correct line items (item, quantity, price) from notes recorded on noisy job sites.

Pass criteria: 90% or more of line items correct, under 10 seconds per note and under $0.05 per note. She collects 100 real voice notes from 8 tradespeople and holds back 40 for the final test.

First result on the held-out set: quiet notes score 94% and noisy ones 78%, for 88% overall, so the test fails. Cost ($0.03) and speed (6 seconds) pass. Her second spike adds a noise filter and asks the model to flag uncertain quantities instead of guessing. Line items correct rise to 91%, and the uncertain ones go to a quick confirmation screen in the product design. She proceeds, with "tap to confirm flagged items" written into the first product version.

What should you measure, and when do you stop?

Metric	Pass signal	Warning signal
Pass criteria met	Every criterion met on held-out data	Criteria changed during the build
Result on realistic test data	Hard cases included and handled at the target rate	Only clean or synthetic data used
Cost per operation	Fits inside your price with room for margin	Cost per use above what customers pay
Weeks and budget used	Within the cap	Cap extended more than once

Stop at the deadline whatever the state of the build. If the result misses the criteria, you get one more round with a new approach and a new cap; two failed rounds mean the product needs a different design or a different technology.

Which mistakes should you avoid?

Testing several assumptions at once. A failure then tells you nothing about which one broke.
Moving the goalposts. Pass criteria are written first and changed only with a written reason.
Using clean demo data. Your customers' real inputs are messier than anything in a tutorial.
Turning the proof of concept into the product. Code written to answer a question fast is the wrong foundation for paying customers.
Building UI to impress investors. A clear result memo with numbers impresses more than a pretty screen with nothing behind it.

How can AI speed this up?

AI coding assistants write the glue code, evaluation scripts and data cleaning in hours instead of days, which suits throwaway work well. They can also suggest two or three alternative approaches to try as spikes. Check every metric calculation yourself, since a bug in an AI-written evaluation script produces a false pass. Keep the held-out data out of any prompt during the build.

The free AI for startups module of the F/MS startup school covers how founders without a technical background can use AI tools for experiments like this, and AI co-founder collects resources for founders building their first product with AI.

Where does this SOP fit in your validation plan?

A proof of concept follows the feasibility assessment and comes before product build.

Find the assumption to test with the technical feasibility assessment SOP.
Choose the tools for the full build with the technology stack validation SOP.
Check speed and stability of the real product later with the technical performance testing SOP.
Test what users see with the prototype testing SOP, in parallel.

See all Technical Validation SOPs. When you present the result to investors, the free pitch playbook module shows how to turn a proof of concept into a credible traction slide.

FAQ

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

A proof of concept tests whether the technology works. A prototype tests whether people understand and want the product. Most technical startups need both, in that order or in parallel.

How long should a proof of concept take?

Two to six weeks. Longer than that and it has turned into a product build without the planning a product build needs.

How much does a proof of concept cost?

$1,000 to $10,000 for most software and AI tests, mostly builder time and test data. Hardware costs more because of parts and prototyping.

Should I keep the proof of concept code?

Keep the test data, the evaluation scripts and the learnings. Rebuild the product code properly, since shortcuts that were fine for a test become problems with paying customers.

Proof of Concept SOP