POC to Production: Using a GCC for Rapid Prototyping

Almost every organisation can build a proof of concept. Very few can reliably turn one into a production system, and the failure is so consistent that it has become an accepted cost of doing exploratory work. Prototypes get built, demonstrated, approved in principle, and then quietly never shipped.

The usual explanation is that the prototype needed to be rewritten and there was no capacity. That is a description rather than an explanation. The real gap is that a proof of concept and a production system answer different questions, and almost nobody plans for the work of moving between them.

This guide covers what the gap actually consists of, why the two most common responses both fail, and how to structure prototyping so that the transition is a planned step rather than an unfunded surprise.

What the gap actually consists of

A proof of concept succeeds if it answers a question under conditions you chose. A production system has to work under conditions chosen by users, continuously, while being maintained by people who did not build it. Almost all the difference is in that sentence.

The work that separates them is largely unglamorous and largely operational. It is rarely the interesting part of the problem, which is precisely why it is consistently underestimated by the people who built the prototype and had a good time doing it.

None of these rows is about the algorithm or the core idea. The gap is operational, which is why the team that built the prototype often underestimates it so badly.

Why the two obvious fixes both fail

The first response is to build prototypes to production standards from the start. This eliminates the rewrite and eliminates the point of prototyping. Exploration is valuable precisely because it is cheap enough to be wrong, and a prototype carrying full production overhead costs several times more and takes several times longer, which means fewer questions get asked and the ones that do get asked are safer.

The second response is to throw the prototype away and rebuild from scratch. This is cleaner in principle and routinely loses the most valuable output of the exercise, which is not the code but the accumulated understanding of why certain approaches failed. A rebuild by a different team reliably rediscovers those failures at full cost.

The workable answer sits between the two: keep prototypes genuinely cheap, and plan a funded, staffed transition step that carries the knowledge forward with the people who hold it.

Decide the production question before you start

The most effective intervention costs nothing and happens before any code is written. Ask what would have to be true for this to reach production, and who would own it if it did.

This reframes the prototype. Instead of demonstrating that something is possible, it is now answering the specific question that stands between the idea and production. Frequently that question is not the interesting technical one; it is whether the data is available at the required freshness, whether the latency budget is achievable, or whether an existing team has capacity to operate it.

It also produces the most valuable outcome available: discovering early that there is no plausible production owner. An idea with no home has already failed, and learning that in week one costs a conversation rather than a quarter.

Structure the work in three funded stages

Treating exploration and productionisation as one undifferentiated activity is what causes the gap to be unfunded. Three stages, each with its own exit condition and its own budget, makes the transition a planned step.

Stage two is the step almost nobody runs, and it is the cheapest of the three. A week of honest assessment routinely prevents a quarter of hardening work on something that was never going to be operable, and it converts an unbounded rewrite into a scoped piece of work with a number attached.

Where the effort actually goes

When teams estimate the transition, they usually estimate the code. The chart below shows the more typical distribution, and the reason estimates are so consistently low.

Who should do the hardening

Handing a prototype to a different team to productionise is the most common structure and among the least effective. The receiving team inherits code without the reasoning, discovers the same dead ends, and frequently concludes it would be faster to start again, which is often true and always expensive.

The better structure keeps at least one person from the prototype involved through hardening, and brings the receiving owner in during stage two rather than at handover. The knowledge that matters is why certain approaches were abandoned, and that is almost never written down in a form that survives a handover document.

• At least one person from the prototype team continues through hardening
• The receiving owner is involved from stage two, not at handover
• The production readiness assessment is written down and shared, not held verbally
• Reasons for rejected approaches are recorded, because that is the knowledge that transfers worst
• Hardening is funded from a separate budget so it does not compete with exploration

Failure patterns

Each of these produces the same visible outcome, which is a demonstration that never ships.

• No production owner identified before the prototype started
• Hardening funded from the exploration budget, so it competes with the next question and loses
• The prototype team dissolved at the demonstration, taking the reasoning with them
• Production readiness never assessed, so the transition is an unbounded rewrite
• The prototype built to production standards, making exploration too slow to be useful
• Success measured in prototypes produced rather than systems adopted

Frequently asked questions