You built something real with Claude. It works in the demo. Here are the twelve gaps that separate that demo from a system you can bet a business on — the same list we work through on every engagement. Take it and run it yourself. If you get stuck on three or more, that's the wall we exist for.
The demo has one user: you. Production has strangers — sessions, roles, password resets, and every route checked, not just the important ones. (A human reviewer default-passing the "unimportant" routes is how nine unauthenticated routes once shipped past a senior engineer — see the proof page.)
API keys pasted into the prototype are the first thing to leak and the last thing you'll remember doing. Production keeps credentials in managed stores, rotated, never in the repo.
Health data, payments, minors, other people's customers — each carries obligations (HIPAA, PCI, consent) that a chat prototype never had to think about. Compliance is architecture, not paperwork added later.
A demo is verified by watching it work once. A product is verified by a suite that runs on every change — because the change that breaks it will be one you didn't think was related.
Production code should reach users through a gate — staged, smoke-tested, reversible — not a manual upload while holding your breath. Rollback is a re-deploy of the last good version, planned in advance.
Uptime monitors, error tracking, and a page to a named human. A dead integration discovered by your customer is a support miss, not bad luck.
The Gmail/calendar/carrier integration that works today runs on tokens that lapse or get revoked — silently. Production watches expiries and refreshes ahead of them.
Anything that charges, pays, or reconciles must halt when uncertain — a run that would charge wrongly stops; it never guesses. Double-charging a real customer is a trust event, not a bug.
If your product uses AI: the examples you show the model are policy, not data — where an example contradicts an instruction, the example tends to win. Non-negotiables belong in code that checks outputs, not in the prompt.
"What touched production and why" should be a query, not a reconstruction. Every change tied to a commit, a deploy, a test result — evidence, not memory.
Incidents happen to real products. What matters is a written order of operations — contain, eradicate, then rotate credentials, verify, tell the affected people in plain language — decided before you need it.
Who owns the code, the accounts, the domain, the data — on payment, in writing. This is the cheapest item on the list and the most expensive to fix later.
30 minutes, no pitch. We'll walk your list and tell you honestly which items you can close yourself.
Book the walkthrough