A proof of concept template is a one-page document a team fills in before building a POC. It has two required fields: the one question the POC exists to answer, and the stop condition that ends the work. As of October 2026, after 15 years shipping platform software in regulated industries, I think most templates miss both. They give you scope, timeline, resources, and risks, then let you skip the only decision that matters. A POC with no written question can never succeed or fail. It can only run out of time. The template below is built to prevent that. It fits on a page, and you can copy it as it stands.
What is a proof of concept template?
A proof of concept template is a one-page document a team fills in before building a POC. A useful one has two required fields: the single question the POC exists to answer, and the stop condition that ends the work. Everything else, like scope and timeline, is there to support those two.
That's a narrower definition than most templates imply. A project plan describes work to be done. A POC document describes a doubt to be removed.
I wrote about what a POC actually is in August. The short version: a POC answers "can this work," and nothing else. This page is the artifact that goes with that idea. If the other article is the argument, this is the form you fill in so the argument survives contact with a real team.
What should a proof of concept document include?
It should include the question, the pass and fail criteria, the stop condition, the smallest build that could answer it, and a decision owner. After the work, add the result and what happens next. Skip anything that describes the finished product, because a POC is not the finished product.
Here is the template. Copy it into whatever tool your team already uses.
PROOF OF CONCEPT: <short name>
Owner: <one person who decides what happens next>
Date opened: <date>
1. THE QUESTION (one sentence, must end in a question mark)
Can we ______________________________________?
2. WHY WE DON'T KNOW YET
What specifically is uncertain? (One or two sentences.)
3. PASS / FAIL
Pass looks like: ______________________________
Fail looks like: ______________________________
4. STOP CONDITION
We stop when: the question is answered, OR
we have spent ____ days / $____ without an answer.
5. SMALLEST BUILD THAT COULD ANSWER IT
(A script, a spike, a test harness. No interface unless
the question is about the interface.)
6. NOT IN SCOPE
(Error handling, logging, polish, anything for real users.)
--- fill in after the work ---
7. RESULT
Pass / Fail / Inconclusive, and the evidence in one paragraph.
8. DECISION
Build / Change approach / Stop. Decided by <owner> on <date>.
Eight fields, and the first two are the whole point. If you can't fill in field 1 in one sentence, you aren't ready to start a POC. Field 6 matters more than it looks. It's where you give yourself permission not to polish.
Why do most proof of concept templates fail?
Most templates are project-plan boilerplate: scope, timeline, resources, risks. None of those fields forces a team to say what it does not know. Without that sentence, the POC drifts into a small version of the real build, with no point at which anyone can say it worked or it didn't.
This is my reading of the templates I've seen, not a survey. I'd treat it as an opinion until someone counts.
Here's what I've watched happen. A team fills in a plan with a scope paragraph and a two-week timeline. The work starts. Week one produces something that half-works, and nobody can say whether that counts. Week two produces something that more-than-half-works. By the end, there's a demo, and the demo gets a standing ovation. The question was never written down, so nobody can say whether it was answered.
How do you write the question for a POC?
Write one sentence that starts with "Can we" and ends with a question mark. It must name a specific mechanism, a specific constraint, and a way to check the answer. If a smart colleague could read it and not know what to build, it is still too vague.
Compare two versions. "Can we use AI to improve intake?" is a topic. "Can a model classify intake notes into our nine categories at 90% accuracy on a sample of 200 real notes, running on the hardware the clinic already owns?" is a question. The second one tells you what to build, what to measure, and what a failure looks like.
Notice that the second question has numbers in it. That's the trick. Numbers turn an opinion into a test.
What is a worked example of a filled-in POC document?
A worked example makes the template concrete. The one below is a composite I invented to show the shape, not a real project. The question is narrow, the pass and fail lines are measurable, and the stop condition is written before any code exists.
PROOF OF CONCEPT: Nightly sync check
Owner: Platform lead
Date opened: Monday
1. THE QUESTION
Can we sync the legacy patient-record table to the new API
without corrupting or dropping records?
2. WHY WE DON'T KNOW YET
The legacy table has no unique key on two columns the new
API treats as unique.
3. PASS / FAIL
Pass looks like: 50,000 sample rows round-trip with zero
mismatches in a field-by-field diff.
Fail looks like: any silent drop, or any duplicate we
cannot resolve with a rule we can write down.
4. STOP CONDITION
We stop when the diff is clean or fails, OR after 5 days
without a clear answer.
5. SMALLEST BUILD THAT COULD ANSWER IT
One script and a diff report. No scheduler, no UI.
6. NOT IN SCOPE
Retry logic, monitoring, permissions, anything a user sees.
Look at what's missing. No architecture diagram, no staffing plan, no roadmap. Those belong to the build that follows a pass. If the POC fails, you've saved all of them.
Why does the stop condition matter more than the scope?
A stop condition ends the work even when the answer is unclear. Scope tells you what to build. A stop condition tells you when to quit building. Without one, a POC keeps absorbing time because there is always one more thing to try, and nobody wants to be the person who calls it.
The version in field 4 has two exits on purpose. The first exit is the answer. The second is a budget of days or dollars. If you hit the budget without an answer, that's a result too: "inconclusive at this cost" is something a decision owner can act on.
I have never regretted setting the limit too early. I have regretted setting it after week three, when everyone was invested and the limit felt like an accusation. Write it first. Write it when the work still feels cheap.
How do you write a stop condition for a POC?
Write two lines before any code exists. One says what result counts as a pass. The other says what time or cost ends the work even if the answer is still unclear. A stop condition has to be written first, because nobody sets a fair limit once they are three weeks in.
If your team resists, ask what they'd want to hear from a vendor running a POC for them. Nobody says "keep going until you feel good about it." They say "tell me what you'll prove and by when."
One more thing. A POC that passes doesn't prove users want the product. That's a different risk, and it belongs to the MVP. Don't let a clean pass on field 7 turn into a launch plan on field 8.
What counts as proof of concept documentation after the POC ends?
Proof of concept documentation after the work is fields 7 and 8 of the template, plus the evidence behind them. Keep it to one page: the result, the evidence, and the decision with its owner and date. Anyone who reads it later should know what was proven and what wasn't.
That's the whole record. I'd rather keep a one-page document that gets read than a thirty-page report that doesn't. The next team to face a similar doubt will thank you, and so will the version of you who has forgotten why the decision was made.
If you use this template, change it. Add a field your organization needs, like a compliance reviewer in regulated work. Just don't remove fields 1 and 4. Those two are the template. Everything else is formatting.