The release is not the finish line

A launch is usually judged on the demo: the screens work, the flow is complete, the client is happy. Then the first Monday arrives, a dependency changes, a certificate expires, a deploy fails halfway, and the product that looked finished becomes a support conversation.

A deploy needs a way back

Every deploy should have a route to the previous build that does not depend on someone remembering the exact commit. In our projects the deploy script verifies health after restart and restores the previous build automatically when the check fails. A rollback that requires a calm engineer at 02:00 is not a rollback plan; it is a hope.

Checks should fail before customers do

Health, API contract and SEO checks run around each release. The point is not to collect badges. It is to make the common failures — a dead endpoint, a changed response shape, a page that no longer renders — fail in the pipeline rather than in a customer's browser.

A backup is not a backup until it is restored

Backups ship with the first release, but the existence of a backup file is the least interesting part. A backup that has never been restored is a file, not a recovery plan. The question to ask is not “do we have backups?” but “when did we last prove that one comes back?”

Errors need a destination

Error tracking is part of the release, not an upgrade. Without it, the first report of a failure is a customer email, and the first useful piece of information — the stack trace, the request, the release — is already gone. An error tracker turns an anecdote into a fix.

The runbook is for the person on call

Tests, a short runbook and readable code ship with every project. The runbook is not documentation for its own sake; it is the difference between a handover and a rescue. It should say how to deploy, how to roll back, where the logs are and who to call when the database is the problem.

Ownership makes handover possible

Code, repository, domains and cloud accounts are in the client's name from the first day. Maintenance is optional, with no lock-in. That is not a contractual gesture; it is an operational property. A product you can hand to another team is a product that can survive its builder.

The measure of a launch is not the demo. It is the first Monday, the first failed deploy and the first error nobody expected — and whether the product, and the people running it, know what to do next.