Turn the demo into
something they trust.

Here’s the trap that catches good engineers: the demo went great, the customer is excited, so it must be nearly done. It isn’t. A demo is a single run of the happy path under ideal conditions with you standing by. Production is thousands of runs, including every unhappy path, against systems that fail on their own schedule, with no one watching. The distance between those two is enormous, and it’s invisible from the demo.

Naming that gap is the first act of hardening. A prototype optimized for the demo has, by design, none of the machinery needed to survive real traffic — and that’s fine, until the moment a real user depends on it. Hardening is the deliberate work of building that machinery, and treating it as a real project (not a weekend of cleanup) is what separates deployments that last from ones that flame out three weeks after the applause.

Every external call can time out, rate-limit, error, or silently double-deliver. Design as if it will. These patterns — each with a hands-on challenge in the track — are the core of reliability.

None of this is exotic, and you don’t need all of it everywhere — you need it on the paths that touch the real world. If you internalize one thing, make it idempotency: it’s the pattern that makes every retry safe, and retries are how a distributed system survives a flaky one.

The demo has perfect observability — you’re watching it live. Production has none unless you build it, and on a locked-down deployment you may never see the running system at all. So you instrument it to report on itself.

The bar to clear is simple and unforgiving: could you diagnose a 2 a.m. failure without touching the machine? If the answer is no, you don’t have enough observability yet — and on a deployment where you can’t reach the system, that gap is the difference between a five-minute fix and a lost account.

Demos cut corners that production can’t afford: a key in the code, a value hardcoded to one customer, a deploy you did by hand and couldn’t repeat. Hardening closes them.

The last row is the sleeper. A deployment you can’t reliably reproduce or roll back is a deployment that will eventually strand you — a bad release with no way back, on a system you may not even be able to reach. A repeatable, reversible deploy isn’t polish; it’s the safety net the whole engagement rests on. (The full gate is the POC → production checklist.)

Before you harden, ask whether you should. A prototype was built to be disposable, and its speed came from shortcuts. If those shortcuts are localized — a hardcoded config here, a stub there — hardening in place is efficient. If they’re woven through everything — no error handling anywhere, state smeared across globals, a structure that fought you even in the demo — a clean rebuild informed by everything you learned is often faster and always cleaner.

A hardened system isn’t the finish line — a system the customer’s team can run without you is. So the last act of hardening points at the handoff: the reliability, observability, and repeatable deploys you just built are exactly what make it operable by someone else. Pair them with a runbook (how to deploy, roll back, rotate secrets, and fix the top few failures) and documentation their engineers can actually use, and you’ve turned a demo into an asset they own.

This is the difference between an FDE who ships and one who becomes a permanent, unpaid support team for everything they ever built. Harden it so it survives, then hand it off so it thrives — the checklist covers both, and the discipline of building for handoff from the start is what keeps you free to go solve the next customer’s problem.

The gap between a working proof of concept and something a customer’s team depends on is not mostly code — it is the set of failure modes the POC was allowed to ignore. Writing them as assertions rather than as a document does two things: it makes the gate refusable, and it turns “is this ready?” from a judgement call into a check anyone can run.

The assertion people argue about is the last one, and it is the one that decides whether this is a deployment or a dependency. An engineer of theirs who has deployed the system once, with their credentials, through their pipeline, while you watched, has surfaced every piece of undocumented knowledge you still hold — and that hour is worth more than the document you would otherwise have written instead.