Proof of concept: a non-technical founder’s guide to the PoC

A founder we were getting to know got a $45,000 quote for a PoC. The scope read “validate the technical feasibility of the platform.” Four weeks, three people, a final presentation.

He wanted to know what a PoC was. I wanted to know why the check was the size of an MVP.

Here is where the confusion lives. A PoC, or proof of concept, is a short, cheap experiment that answers one technical question: “Is this possible, and at what cost?”. It is not a product. It is not a prototype. It is not an MVP. It is a risk-reduction exercise you run before you commit the budget for an entire project. At a serious vendor, it lasts one to three weeks, costs $3,000 to $20,000, and the main deliverable is not pretty code. It is knowledge.

If you are a non-technical founder and someone is offering you a PoC, this guide exists to explain what you are actually buying, when it makes sense to pay, and when the word “PoC” became a polite way to bill you for the vendor’s own learning curve.

The PoC, in one sentence

A PoC answers a technical question nobody in your room can answer with confidence. Three examples of what that question looks like, from the real world:

• “Can we sync the data from the clinic’s legacy system into our app without rewriting the legacy?”
• “Can this AI model read our suppliers’ invoices with more than 95% accuracy?”
• “Does the Open Banking API support the use case we promised our pilot customer?”

Each one is a closed question: the answer is “yes,” “no,” or “yes, but.” The PoC exists to reach that answer in days, with throwaway code, before the full project budget is on the line. When the question is not closed (when it is actually “do customers want this?” or “will the market pay for it?”), you do not need a PoC. You need something else, and the next section disambiguates which.

PoC, MVP, prototype, spike: the quick map

Four words, four different instruments, and the market’s vocabulary scrambles all of them. The honest summary:

• PoC. Validates a technical hypothesis. Answers “is this possible?”. Throwaway code. Audience: the product and engineering team. Does not ship to customers.
• Prototype. Validates a design hypothesis. Answers “do people understand this interface?”. Can be a static Figma file or a clickable mock. Shown to users in testing, not in production.
• MVP. Validates a business hypothesis. Answers “does anyone use it, does anyone pay?”. It is small, but it is a product: it goes to real customers, in the real world, with real data. This is the phase most product discovery work is preparing for.
• Spike. The smaller cousin of the PoC, usually inside a single sprint, with no formal deliverable. The team dives into a technical question for two to five days and comes back with a recommendation. Martin Fowler describes the pattern in one page, worth reading.

When someone offers you a PoC and the scope reads “we will build the first version of the product,” you are not looking at a PoC. You are looking at an MVP with the name swapped, and the price almost always confirms it.

What a serious PoC actually delivers

A useful PoC deliverable has four components, and the absence of any one of them is a sign the work was not done with rigor:

1. A report that says “yes,” “no,” or “yes, but.” One or two pages. With the original question at the top and the answer in the second paragraph. If you need to read 30 slides to find the verdict, that is not a report; it is a budget defense.
2. The code (or the artifacts) used to get to that answer. Throwaway or not, it lives in your repo. You paid for it; it is yours. If the vendor says “we keep the code,” that is a sign of something wrong, and the best time to find out is now. This is one of the points that separates a serious software development contract from a template pulled off the internet.
3. An honest list of what was left out. Every PoC cuts corners. Performance, security, edge cases. The deliverable has to name what was skipped, so nobody reads the “yes” in the report as “ready to scale.”
4. An updated estimate for the project that follows. Range of hours, range of risk, range of cost. The whole reason the PoC exists is that the estimate before it was a guess. After it, the guess should narrow.

Notice what is not on the list: finished screens, complete technical documentation, a user manual, a promotional video. PoCs do not deliver that. If a proposal promises all of that for $40,000 in four weeks, somebody is going to be disappointed, and historically it is the founder.

When a PoC makes sense for the non-technical founder

There are four scenarios where it is worth paying for a PoC before the main project. Outside of them, it is usually waste:

1. The project depends on an integration nobody on your team has ever done. Open Banking, legacy hospital ERPs, government registry systems, insurance carrier APIs. If the product’s viability depends on that integration working, and no one can guarantee it on paper, the PoC is cheaper than discovering the problem halfway through the project.

2. The use case depends on an AI model hitting a specific quality threshold. “Extract field X from document Y at 95% accuracy” is a PoC question. “Build an AI platform” is not. When the product’s viability depends on a quantitative model metric, validate that metric first, in isolation, before building the interface around it.

3. The proposed architecture has a six-figure decision baked into it. Microservices or monolith; relational or graph database; cloud A or cloud B. When the wrong choice early on is expensive to reverse later, a PoC focused on comparing two paths pays for itself ten times over.

4. You need factual ammunition for a conversation with an investor or a pilot customer. “Yes, the integration with the customer’s ERP is feasible; here is the technical report” is a different argument from “we think it is feasible.” When the commercial cycle is gated on a technical signal, the PoC buys that signal.

When “PoC” became something else

The word is also used with other meanings, and the non-technical founder has to recognize each one to avoid paying for the wrong thing:

PoC as “cheap MVP.” The vendor calls a PoC what is, in practice, the first version of the product. Usually it is a way to lower the entry price of the project, or to close a sale on a short cycle. There is no problem with buying a small first version. There is a problem with calling it a PoC, because the vocabulary changes the expectations: a PoC is disposable, an MVP is foundation. If you think you are validating feasibility and you are actually building foundation, you will take dangerous shortcuts.

PoC as “paid diagnostic.” Common in generative-AI projects in 2025 and 2026. The vendor charges to find out whether the technology they sell works in your case. In some markets that is reasonable. In others, it is billing you for the vendor’s own learning. The difference is who walks away owning the knowledge at the end: you, or them.

PoC as “disguised discovery.” When what the project really needs is to understand the user’s problem, map processes, run interviews, and the vendor packages it as a PoC to avoid the word “consulting.” It is discovery, it is worth doing, but the correct vocabulary matters: discovery and PoC have different deliverables and different teams.

The four-question test before approving a PoC

Before signing, read the scope of the proposed PoC and answer these four questions. If you cannot answer three of them, stop and send the document back:

1. What is, in one sentence, the question this PoC answers? If the answer is “validate the technical feasibility of the platform,” the scope is vague. You want “validate whether we can sync data from system X into our system Y inside a five-minute SLA.” Specific. Closed. Verifiable.

2. What counts as “yes” and what counts as “no”? The PoC should describe, before it starts, what counts as success and what counts as failure. “More than 95% accuracy” is a criterion. “Show promising results” is not. Without a criterion, any result becomes “yes.”

3. What is left with you at the end? Code, report, data, or just a presentation? Who owns the code? Where is it stored? If the vendor cannot answer those questions directly, the PoC is being sold as a service, not as a deliverable.

4. If the PoC returns “no,” what changes in your next step? If the answer is “we move forward anyway,” you do not need a PoC. You need the courage to start and the discipline to adjust the course. A PoC only makes sense if its result can make you stop.

What it costs, how long it takes, who should do it

Honest ranges, from what we see in serious vendors for custom software in 2026:

• Duration. One to three weeks. Above four, it is not a PoC anymore; it is a project. Below one, it is probably a spike and would not need a separate budget.
• Cost. Between $3,000 and $20,000, with most healthy cases between $6,000 and $12,000. PoCs of $40,000 or more exist (complex integrations, regulation), but the justification bar climbs fast.
• Team. One to three people. Typically a senior engineer who makes the technical calls, occasionally a specialist (security, AI, data), and a part-time product person who writes the report.
• Who should do it. Ideally the same team that would run the full project afterward, or a team that will hand the recommendation to another team to execute. The people who ran the PoC have the context; the people who only read the report will invent half of what they thought they knew. This is one of the reasons staff augmentation is rarely the right model for a PoC: the contract ends and the knowledge walks out the door with the person.

If your proposal falls outside those ranges, ask why. The answer might be legitimate (banking regulation, integration with a federal system, specialized team). Or it might be that you are paying MVP money for a PoC, and the vocabulary was calibrated to fit the budget.

Frequently asked questions

Are PoC and proof of concept the same thing?
Yes. PoC is the acronym; “proof of concept” is what it stands for. The tech market uses both forms, sometimes in the same sentence. No difference in meaning.

What does PoC mean outside the software context?
The acronym shows up elsewhere and scrambles search. In construction, “POC” can be a percentage-of-completion measure. In medicine, it is “point of care.” This guide is only about the software PoC.

PoC, MVP, or prototype: which one should I start with?
Depends on the question you need to answer. If the doubt is technical (“is this possible?”), start with the PoC. If the doubt is about design (“do people understand this?”), start with the prototype. If the doubt is about the market (“will anyone pay?”), skip straight to the MVP. None of the three is “earlier” than the others: they are instruments for different questions.

Can I skip the PoC and go straight to the project?
Yes, and in most cases that is what makes sense. PoCs are only worth it when there is real technical uncertainty that can kill the project and that is expensive to discover later. If your product is a version of something that already exists, on a known stack, the PoC becomes process theater.

How long does an AI PoC take?
Same rule as the others: one to three weeks to answer one specific, closed question. AI PoCs that run for two months are usually not validating a hypothesis; they are building a product without saying so.

Will the PoC code become the base of the product?
No, and this is the hardest part to accept. PoC code is optimized for speed of answer, not for maintenance. Most of it will be thrown away when the project starts. What carries forward is the learning, captured in the report and in the heads of the people involved. If a vendor promises that the PoC code “will reuse 80% for the product,” be wary: either the PoC will become a bad MVP, or the product will inherit shortcuts that looked cheap in the moment and stay expensive forever.