Ship the Boring Version First

Every project starts with a design that handles cases you have not encountered. Most of them never arrive.

What the boring version teaches

Real usage answers questions that planning cannot: which pages people actually open, where the data model creaks, what is slow. A week of production traffic beats a month of speculation, and it costs less.

The cost of premature structure

Abstractions written before the second use case are fitted to an imaginary one. They are harder to delete than they were to write, because deleting them means admitting the design was wrong — so people work around them instead. That is how codebases calcify.

What is worth doing up front

Not everything defers. Get these right early because retrofitting them is genuinely painful:

• Security boundaries. Bolting on auth later means auditing every path.
• Data you cannot recreate. Backups, and identifiers you will not want to change.
• The build/deploy loop. Slow feedback compounds across every future change.

Everything else can wait for evidence.

The honest version of "we'll fix it later"

Sometimes later never comes, and the boring version is still running years on. That is usually fine — and when it is not, you will have real data telling you exactly what to fix.