The dirty secret of the proof of concept is that 'we'll rewrite it properly later' almost never happens. The PoC that demoed well becomes the thing in production, load-bearing and unloved. So we build it assuming that is exactly what will occur.
Prove the risk, not the demo
A PoC exists to retire a specific uncertainty — technical, integration, or performance. When it is built to impress a room instead, it proves nothing that matters and leaves every real risk untouched. We start by naming the single question the PoC has to answer, and we build the smallest thing that answers it honestly.
What we refuse to fake
- The boundary that will be hardest to change later — we get it right the first time.
- The data model at the core — cheap to shape now, brutal to reshape after launch.
- The one integration everyone is nervous about — proven for real, not stubbed.
- The failure paths — because production is mostly failure paths.
What we happily fake
Everything else. Screens can be crude, breadth can be narrow, polish can wait. The discipline is spending the budget on the parts that are expensive to change and starving the parts that are cheap. A reusable PoC is not a smaller product; it is a product with the load-bearing decisions made and the cosmetic ones deferred.
Build the parts you cannot cheaply undo. Fake the parts you can.
The handover that matters
We leave behind the reasoning, not just the repository — the decisions taken, the constraints assumed, the paths deliberately left open. That is what lets the next team extend the PoC instead of restarting it. The code is the smaller half of the deliverable.
Assume the PoC ships. Build the one you would not be ashamed to inherit.