TL;DR
A proof of concept answers “can this work at all” and is judged by your own engineers. A pilot answers “does this hold up in real operation with real users” and runs in production at limited scale. A PoC that produces a clear no is a success. A pilot that produces a clear no has cost you three to five times more, which is why running one before a PoC is the most common and most expensive mistake in this sequence.
Rough shape: a PoC is two to four weeks and settles one technical unknown. A pilot is six to twelve weeks, involves real users and real data, and settles whether the thing survives contact with an actual operation.
PoC vs pilot at a glance
| Proof of concept | Pilot | |
|---|---|---|
| Question it answers | Can this work technically? | Does this work in real operation? |
| Who judges it | Engineers and architects | Real users and the operations team |
| Data | Sample, synthetic or a copied slice | Live production data |
| Users | Usually none | A real but limited group |
| Environment | Sandbox, throwaway | Production or a mirror of it |
| Typical length | 2 to 4 weeks | 6 to 12 weeks |
| Typical output | A written verdict plus throwaway code | A running system and an operational decision |
| Success looks like | A confident yes or no on the unknown | Adoption, stability, and a rollout plan |
| Failure costs you | A few weeks | A quarter, plus internal credibility |
| Is the code kept? | Usually not, and that is fine | Usually yes, it becomes the foundation |
| Security review needed | Rarely | Always |
| Typically paid for by | Innovation or engineering budget | The business unit that will own it |
The row people skip is “is the code kept”. A PoC is allowed to be disposable. If somebody promises a proof of concept that also becomes your production codebase, you are being sold a pilot at PoC prices (our MVP vs PoC post covers the third artefact people confuse with both), and the shortcuts taken to hit the PoC timeline will live in your product for years.
What a proof of concept actually is
A PoC exists to remove one specific doubt. The discipline is in the word *one*, and good PoCs are narrow to the point of looking unimpressive to anyone who was not in the room when the question was framed.
The one-question rule
If you cannot write the unknown as a single question with a yes or no answer, the scope is not ready. Real examples of a well-formed PoC question:
- Can we extract structured data from these particular supplier invoices at an accuracy the finance team will accept?
- Will this legacy system let us read the records we need without a vendor contract we cannot get?
- Can the model run inside our latency budget on hardware we can afford?
- Can these two systems be reconciled at all, given neither has a stable identifier for the same customer?
- Does this API return the fields the process actually needs, or only the fields the documentation advertises?
Notice what none of them mention: user experience, design, scale, onboarding or adoption. Those are real questions and they belong to other stages. A PoC that tries to answer them stops being a PoC and becomes a slow prototype.
What a PoC produces
Three things, and only one of them is code:
A written verdict. Yes, no, or yes-with-conditions, in language a non-technical sponsor can act on.
The numbers behind it. Accuracy rates, latency figures, throughput, error rates. Whatever metric the question was framed in.
Throwaway code. Enough to have run the experiment honestly, not enough to deploy. Nobody should be maintaining it in six months.
Paying for a two week PoC and receiving “no, not at that accuracy” is a good outcome. It is a fraction of the cost of discovering the same thing in month five with a team assembled around it.
What a PoC is not
It is not a demo, though it is often mistaken for one. A demo is built to persuade; a PoC is built to find out. It is not a prototype, which tests whether people understand a flow. It is not a small version of the product. And it is emphatically not a free sales exercise, which is the framing that produces PoCs designed to succeed.
What a pilot actually is
A pilot is a real deployment with the blast radius turned down. The system is live, the data is real, the users are real, and the only thing limited is how many of them there are.
Limited means users, not features
This is the misunderstanding that ruins pilots. Teams cut features to make a pilot smaller, then discover the feature they cut was the one that decided adoption. A pilot has to be complete enough to be genuinely used, or the result tells you nothing about the real thing.
Limit the population instead: one depot, one region, one team, one customer segment. Keep the product whole.
What a pilot produces
An operational decision. Roll out, iterate, or stop. Made by the people who will live with the system.
Evidence in the form of usage. Not opinions gathered in a workshop. Whether people used it when nobody was watching.
A running system. Usually the foundation of the eventual rollout, which is why ownership of the code matters far more here than in a PoC.
A cost picture. Support load, licence consumption, infrastructure spend under real usage. Almost always different from the estimate.
What a pilot is not
It is not an extended trial of a vendor’s demo environment. It is not a beta, though the software may be in a similar state, because a beta assumes you have already committed and are hunting defects. And it is not a PoC with more time, because a pilot answers a different question entirely.
The five differences that actually decide it
| PoC | Pilot | |
|---|---|---|
| The unknown | Technical | Behavioural and operational |
| The judge | Engineering | Operations and end users |
| Consequence of failure | An answer, cheaply | Real users lost time |
| What you keep | A decision | A system |
| Where it lives | Sandbox | Production |
If you can only remember one, remember the second row. A PoC judged by operations will drift into a pilot. A pilot judged by engineering will declare success because it worked, while nobody used it.
The sequence, and the expensive way to get it wrong
The order is not a formality. Each stage exists to stop you spending the next stage’s budget answering a question the current stage could have settled.
PoC then pilot
Correct when there is genuine technical doubt. Settle the unknown cheaply, then test the answer in the real world. This is the default and it is the right default.
Straight to pilot
Correct when there is no technical doubt at all, only operational doubt. If the technology is proven, deployed elsewhere, and the only question is whether your people will adopt it, a PoC is theatre and it delays you by a month.
Pilot first when you did have technical doubt
The expensive mistake. You have committed a production deployment, a security review, real users and their attention to a question a two week sandbox exercise could have answered. When it fails it fails publicly, and the next attempt is harder because people now believe the idea does not work rather than that the sequence was wrong.
The tell that you need a PoC: somebody says “it should be possible” and nobody can point to a time they have seen it done with data shaped like yours.
Who runs each one
A PoC needs engineers and one decision-maker
A small technical team, plus one person empowered to accept the answer. That second role is the one usually missing. A PoC that reports into a committee produces a discussion rather than a decision, and the finding gets softened on the way up.
A pilot needs an operational owner
Someone whose job the system affects, who will use it, and whose judgement the organisation trusts. Not the sponsor, and not the innovation team.
The sponsor problem
Pilots judged only by the person whose idea it was almost always pass. This is not dishonesty, it is ordinary human investment. Structure the judgement so the person deciding is not the person who championed it, or accept that the result is a formality.
Success criteria: write the exit condition first
A stage with no failure condition is not an experiment, it is a budget with a deadline attached. Both stages need their exit written down before work starts, and both are easy to write badly.
PoC exit criteria
Numeric and specific. “Extraction accuracy above 95 percent on a sample of 500 real invoices, measured against manual entry.” Not “demonstrate feasibility.”
Pilot exit criteria
Behavioural and numeric. “Sixty percent of the depot team log in unprompted in week three, and average handling time does not increase.” Not “positive user feedback.”
Why “it went well” is not a criterion
Because everything goes well when nothing is being measured. If the criteria are written after the results are in, they will be written to match the results. Write them first, share them, and hold to them even when the answer is inconvenient.
What each one costs
Nobody publishing on this topic gives a number, which is exactly why the question is hard to research. These are ranges and shapes, not quotes, and scope moves them far more than any other factor.
| Proof of concept | Pilot | |
|---|---|---|
| Typical duration | 2 to 4 weeks | 6 to 12 weeks |
| Engineering effort | One narrow workstream | 3 to 5 times a PoC |
| Security review | Rarely needed | Always, and often the critical path |
| User training | None | Real, and usually underestimated |
| Support during | None | A named person, business hours minimum |
| Exit plan | Delete the repo | Migration or decommission plan |
| Cost of a “no” | The PoC itself | The pilot, plus internal credibility |
What moves a PoC quote
How many unknowns you bundle. One question is a PoC. Four questions is a project wearing a PoC label, and it will take four times as long.
Whether real data is involved. The moment production data enters, you inherit access approvals and a security review, which frequently costs more than the engineering.
How hard the data is to get. Not the volume. Whether anybody knows where it lives and who can approve a copy.
What moves a pilot quote
How many integrations are live. Reading from one system is ordinary. Writing back to three, each with its own outages, is a different project.
How many users, and how trained. Twenty users who already understand the process is not the same as two hundred who do not.
What happens when it breaks. A pilot with no support path is a pilot that ends the first time somebody is blocked at 4pm.
The costs people forget
Security review time, data access approvals, user training, the operational hours your own team spends, and the exit plan if you stop. In regulated environments the review is routinely the longest single line, and it is almost never in the first estimate.
For a like-for-like sense of what a scoped software build costs once you are past these stages, the MVP cost calculator gives a range in seconds, and the proof of concept cost breakdown goes deeper on the PoC end specifically.
How long each takes, realistically
| Phase | PoC | Pilot |
|---|---|---|
| Framing the question or scope | 2 to 5 days | 1 to 2 weeks |
| Access, approvals, security | 0 to 5 days | 2 to 6 weeks |
| Build | 1 to 3 weeks | 3 to 6 weeks |
| Run and observe | Not applicable | 4 to 8 weeks |
| Decision and write-up | 2 to 3 days | 1 to 2 weeks |
The row that surprises people is approvals on a pilot. Teams plan the build and forget that touching production data in a regulated environment can take longer than writing the software.
Data and security: the part that delays pilots
PoC data
Sample, synthetic, or a copied slice with identifiers removed. The goal is data shaped like production, not production itself. A PoC that insists on live data has usually not been scoped tightly enough.
Pilot data
Real, which means real obligations. Access control, retention, audit logging, and a defensible answer to who can see what. This is where a pilot stops being an engineering exercise.
The approval that takes longer than the build
In regulated industries the security and data review commonly runs longer than the development. Start it in parallel with scoping rather than after the build, and treat the reviewer as a stakeholder rather than a gate at the end.
Paid pilots versus free pilots
Why free pilots cost more
A free pilot has no internal owner with something at stake. (The same logic decides whether to charge design partners.) Nobody schedules training, nobody chases adoption, and when it competes with real work it loses. The most common way a pilot dies is not a technical failure; it is quiet non-use because nobody committed anything to it.
What commitment looks like
Money is the clearest form, but not the only one. Named users with allocated time, an executive sponsor with a stake, an agreed decision date, and a written statement of what happens if the criteria are met. Any of those create the pressure that makes a pilot real.
The vendor’s incentive
If the team running your PoC also wins the implementation contract when the answer is yes, they have an interest in the answer. Ask directly what a no would look like and how it would be reported. A supplier who has never delivered a negative PoC verdict has either been extraordinarily lucky or is not really running PoCs.
Structuring the agreement
What belongs in a PoC agreement
The single question. The success metric and its threshold. The data being provided and what happens to it afterwards. Who owns the code, which for a PoC matters less but should still be stated. And the deliverable, which is a written verdict rather than software.
What belongs in a pilot agreement
Everything above, plus: the user population, the support arrangement and hours, the decision date, what happens to the data and the system if you stop, and the commercial terms if you proceed. That last one is worth agreeing before the pilot rather than after, when your negotiating position is weakest.
Ownership, and why it decides the endgame
Pilot code usually becomes the foundation of the real system. If the repository, the infrastructure and the IP are not yours from the first commit, a successful pilot leaves you negotiating with the only people who can operate what you now depend on. Make ownership a starting condition, not a handover milestone.
Turning a successful pilot into a rollout
A pilot that passes is not a rollout that will. Three things change at scale:
The users get less motivated. Pilot participants are volunteers or selected. Everyone else is not.
The edge cases get more common. A one percent case is invisible with twenty users and constant with two thousand.
The support model has to become real. What one engineer absorbed during a pilot becomes a queue.
Budget for the gap between the pilot and the rollout explicitly. The most common post-pilot failure is treating rollout as a copy-paste of something that worked.
Where MVP and prototype sit
PoC and pilot are two of four stages that get mixed up, and it is worth placing the other two precisely because the difference is what gets built.
- Proof of concept. Can it work technically? Judged by engineers.
- Prototype. Does the flow make sense to a person? Judged by users, but nothing behind it is real.
- MVP. Does a minimal but genuinely working version deliver enough value that people keep using it? Judged by the market.
- Pilot. Does the full thing hold up in a real operation at limited scale? Judged by operations.
A prototype can be clickable and completely hollow. An MVP is small but works. A pilot is not small, it is limited in who can reach it. We have written up MVP versus PoC, MVP versus pilot and MVP versus prototype separately, in detail, if you need the pairwise comparisons. The PoC and prototype pair has its own post in PoC vs prototype.
How this plays out by industry
Logistics and supply chain
The PoC question is usually integration: can we read from the TMS or the carrier feed at all, reliably. The pilot question is whether planners trust the output enough to stop maintaining their spreadsheet in parallel. The spreadsheet is the real competitor.
Life sciences and regulated manufacturing
Validation dominates. A PoC can run outside the validated environment; a pilot usually cannot, which is why the gap between them is larger here than anywhere else. Plan qualification work as part of the pilot rather than after it.
Automation and RPA
The PoC proves the bot can complete the process on clean cases. The pilot discovers what proportion of real cases are clean, which is the number that actually decides the business case and is almost always lower than the process owner believes.
Startups selling to enterprise
Here PoC and pilot are sales stages as much as technical ones. The thing to protect is the exit: an agreed decision date and a written statement of what success triggers. Without them a pilot becomes indefinite free work.
Five questions that decide which one you need
- Can you write the unknown as a single yes or no question? If yes, that is a PoC. If the answer needs a paragraph, neither stage is ready.
- Would a technical no stop the project entirely? If yes, do the PoC first regardless of how confident the room sounds.
- Is the doubt technical or behavioural? Technical goes to a PoC. Behavioural, meaning will people actually use it, needs a pilot.
- Can you expose real users without real consequences if it fails? If not, you are not ready for a pilot whatever the calendar says.
- Do you know what result would make you stop? Write it down first.
Common mistakes, in order of how much they cost
Running a pilot to answer a technical question. The most expensive error on this page.
Bundling four unknowns into one PoC. Produces a slow project and an ambiguous answer.
Cutting features to make a pilot smaller. Limit users instead.
No written exit criteria. Guarantees the result is whatever the loudest person says it is.
Letting the PoC become production. The shortcuts stay for years.
Free pilots with no committed owner. They die of neglect, not failure.
Discovering the commercial terms after a successful pilot. Your leverage is highest before it starts.
Who builds it
Both stages are commonly outsourced, and for good reasons: they are bounded, they are short, and pulling your own engineers off the roadmap for a four week detour is usually the more expensive option.
Two things matter more than which supplier you pick.
A PoC must be allowed to fail. Ask what a no looks like and how it gets reported, before you sign.
A pilot must produce something you own. Repository, infrastructure and IP yours from the first commit, not handed over at the end.
We run proof of concept engagements on exactly those terms: one question, two to four weeks, a written verdict with the numbers behind it, and a plain no when the answer is no. The customers who run a pilot with you are usually the same people described in our post on design partners.
Frequently Asked Questions
Is a pilot the same as a beta?
Close, but the emphasis differs. A beta usually hunts defects in a product you have already committed to shipping. A pilot decides whether to commit at all. The same software can be in both states, but the question being asked is not the same, and so the success criteria are not either.
Can a PoC become the real system?
It should not. PoC code is written to answer a question quickly, which means shortcuts that are correct for a PoC and wrong for production: no error handling, no tests, credentials in config, no thought about scale. If it does get promoted, budget the rewrite honestly at the time rather than discovering it eighteen months later as unexplained slowness.
How long should a PoC take?
Two to four weeks. If a proposal says twelve, the scope contains more than one question. Splitting it will get you a usable answer sooner and cheaper, and often the first answer makes the rest unnecessary.
Do we need a PoC if the technology is well established?
Usually not. If the doubt is only whether it works in your environment with your data, a short technical spike or a discovery engagement may be enough. A PoC is for genuine uncertainty, not for reassurance, and running one out of habit costs a month.
Who should judge a pilot?
The people who will live with it, not the people who sponsored it. Pilots judged only by their champion almost always pass, which makes the exercise decorative. Name the judge before the pilot starts.
What if we cannot get access to real data for a pilot?
Then you cannot run a pilot yet, and that access problem is the thing to solve first. Running a pilot on synthetic data is a PoC wearing a pilot’s budget, and it will not answer the operational question you paid for.
Should a pilot be paid?
Generally yes, and the reason is commitment rather than revenue. A free pilot tends to have no internal owner with something at stake, so training does not get scheduled and adoption does not get chased. If money is genuinely not possible, substitute another form of commitment: named users with allocated time, a sponsor, and an agreed decision date.
What is the difference between a PoC and a feasibility study?
A feasibility study is usually analysis: desk research, architecture review, expert judgement, no working code. A PoC builds the smallest thing that can actually test the claim. When the question is “has anyone done this”, a study is enough. When it is “can it work with our data”, build something.
How many users should a pilot have?
Enough that the result is not one person’s opinion, and few enough that you can support them properly. In practice one natural unit works best: a single depot, team, region or customer. Keeping the group organisationally coherent matters more than the headcount.
What happens if the PoC says no?
You saved the pilot budget, which is the entire point. A no is a successful PoC. The failure mode to watch is a no that gets softened into a “yes, with some caveats” on the way to the sponsor, which converts a cheap answer into an expensive one.
The short version
Use a PoC when a single technical question could kill the project. Use a pilot when the technology is not in doubt but the real world is. Get the order wrong and you pay a pilot’s price for a PoC’s answer.
If you already know which one you need and want it built, we scope it on a call, put a fixed number in front of you, and tell you on that call if we think the stage you have picked is the wrong one.
