The boring half of shipping software

Roughly half of what we are paid for is invisible in a demo. It is the part that decides whether the visible half is still standing in a year, so it is worth describing plainly.

A deploy you can undo is worth more than a deploy that works

Anyone can ship on a good day. The question is what Thursday at 17:40 looks like when the good day ends. We keep every release revertible in one step, which sounds obvious and quietly rules out a long list of convenient shortcuts — irreversible migrations, schema changes tangled into feature code, configuration that lives only in someone’s head.

Migrations run twice, on purpose

A migration that cannot be run twice without breaking is a migration that cannot be retried, and anything that cannot be retried will eventually fail halfway. Writing them to be repeatable costs an hour and removes an entire category of bad evening.

The unglamorous list

• Every environment variable a build needs is declared and checked, not discovered at runtime.
• The staging database is restored from production regularly, so the restore is known to work.
• Error reports carry the request and the user, because a stack trace alone rarely finds the bug.
• Performance budgets fail the build, not a dashboard nobody opens.

Why this ends up in the price

Clients occasionally ask to skip this half to move faster, and for a prototype meant to be thrown away that is the right call. For anything that a business will depend on, it is the difference between software that is an asset and software that becomes a liability the moment its author leaves.

We wrote about where this gets decided — before any code is written — in the piece on discovery.

The software discovery phase