Proof of Concept

For a long time the answer to "can we build this?" was "we'll find out when we try." That isn't wrong, but it doesn't help anyone decide. The person asking can read the same sentence as a yes or as a no, and usually reads it as whichever one they wanted.

So the decision went one of two ways. Either nobody touched the idea, because no one wanted to stake a quarter of the roadmap on a guess, or the team scheduled four months of work and hit the wall in the final week. The first way gives up work that was possible all along. The second spends four months and three engineers' salaries and leaves nothing behind. Plenty of proposals ended with "let's start and change course if it doesn't work," and six months later the same item was back on the same agenda with nothing learned.

A proof of concept (PoC) buys that decision up front. Instead of committing four months, a team spends two weeks running the single riskiest piece for real, finds out whether it holds, and makes every other decision after that. Among the small things teams build before the finished product, the PoC is the one that deals with technical uncertainty. It is deliberately the cheapest of them, because its whole job is to be cheaper than the mistake it prevents.

Pick one question, write the least code that can answer it, run it inside a fixed window, and then judge what came back.

1. Write the assumption as a single sentence. "We can search 100,000 documents at once and return results in under a second" can come back true or false. "We can improve search" can't be judged, so it isn't an assumption.
2. Set the pass and fail lines as numbers before you start. Under one second passes, over three seconds fails. Decide that at the end instead, and every ambiguous result gets read as a pass, because by then somebody has already planned around a yes.
3. Fix the window and the headcount first. Two weeks, one engineer. If no answer arrives inside the window, that counts as no answer. Leave the window open and the PoC quietly turns into the project itself.
4. Build only the riskiest part. Login, screen design, error handling and permissions all come out. Loading the data by hand and printing results to a terminal is fine.
5. Judge the result and throw the code away. What you keep is a one-page record of what you checked and under which conditions.

Teams usually flinch at that last step. The output of a PoC is a conclusion, not a codebase. Code written in two weeks with no error handling becomes technical debt the moment it ships — shortcuts you skipped cleaning up, charging you interest in lost time later.

It fits when the risk sits in the technology. You are reasonably confident people want the thing, and the open question is whether it can be built at all — the case where feasibility risk is the largest risk on the list. Whether an unfamiliar external service can handle your data shape, or whether response times reach the level promised in a contract, are questions of that kind. So is anything where the honest estimate is a range of several months wide, since a range that wide is a sign that nobody knows yet.

Three situations call for something else. When you don't know whether anyone will use the thing, ship an MVP to real users instead. When the open question is whether people can follow a flow on screen, a prototype answers it faster. When a finished feature needs proving in live operation, a pilot opened to a handful of customers is the right shape.

The limits are just as clear. First, a successful PoC says the technology works, not that the feature will sell. Second, a result that holds at small scale can collapse at real scale: 0.4 seconds across 10,000 documents does not become 4 seconds across a million. Third, results run generous when the person who built it also grades it — ten runs come back between 0.8 and 4 seconds, the average goes into the summary, and the summary says pass. Splitting the person who wrote the criteria from the person who reads the results takes most of that away.

"Let's give this two weeks as a PoC and decide after."

Strip out the technical risk before anyone approves a four-month plan.

"The PoC worked, but we can't ship that code as it is."

The question is answered, so now the real version gets built from scratch.

"That's not a PoC question. That's a question for users."

The uncertainty is demand, not technology, so the method is wrong.

At Pagedeck this came up while the team was weighing a feature that searches inside documents by meaning rather than by exact words. Mia wrote down the line first — 100,000 documents, under one second — and Theo spent two weeks running only the search layer, with no screens and no login, printing results to a terminal. It came back at 0.8 seconds.

What those two weeks decided wasn't whether to build the feature but which of three approaches to build it with, since only one cleared the line. Had all three come in over three seconds, the feature would have dropped out of the quarter, and that would have been the same two weeks well spent.

The most common mistake is treating a failed PoC as failed work. Two weeks went in and the answer came back negative, so it looks like time thrown away. But a negative answer is exactly what was being bought: a fact that would have surfaced four months in arrived in week two, which is fourteen weeks saved. Where that counts as a failure, nobody proposes a PoC again, and uncertain ideas go straight onto four-month schedules.

Reading a pass as permission to build is the other one. The word proof suggests something has been settled, and something has — one technical question. Whether the feature is worth building is a question the PoC never touched. Blur the two and you end up with a feature that runs beautifully and that nobody opens. The clean version of the sentence is narrow on purpose: this can be built, and that is all it says.