What "Production-Ready" Actually Means

"It works on my machine" and "it is ready for your customers" are separated by a body of work that is invisible in a demo and decisive at 2am. When a build feels 90% done for a suspiciously long time, this is usually what remains.

It handles being wrong

Every external call fails eventually. Production code assumes it: timeouts set deliberately, retries with backoff on the calls worth retrying, and a user-visible state for failure that is neither a blank screen nor a stack trace.

The corollary is that errors must be observable. An error swallowed silently is worse than a crash, because a crash gets fixed.

It can be observed

• Structured logs with enough context to trace one request.
• Error tracking that reaches a person, not a dashboard nobody opens.
• Uptime and latency monitoring with alert thresholds agreed in advance.
• A way to answer "is it slow for everyone or just this user".

It can be deployed and undeployed

Deployment should be one command or one merge, repeatable by someone who did not write the code. Just as importantly, it should be reversible — a rollback path that has been used at least once, before you needed it.

Database migrations deserve specific attention, since they are the part of a rollback that does not automatically reverse. Forward-compatible migrations are slower to write and much cheaper to live with.

A backup that has never been restored is not a backup. It is a belief.

It is secure in the ordinary ways

• Authentication and authorisation checked on the server, per request.
• Secrets in environment configuration, never in the repository.
• Input validated at the boundary; parameterised queries throughout.
• Dependencies scanned, with a route to patching a critical CVE this week.
• Backups automated, and a restore that has been tested.

Someone else can maintain it

The final test is unsentimental: if the original developer disappeared, could a competent engineer make a change safely next month? That requires a README that explains how to run it, types or tests that catch the obvious mistakes, and code organised the way the domain is, not the way the tutorial was.

This is what you are buying when you pay for engineering rather than for a demo. Not cleverness — the absence of surprises.