How I Approach Building Production Web Apps

Most projects do not fail at the code. They fail earlier, at the point where nobody wrote down what the thing is supposed to do, and later, at the point where nobody could deploy it twice the same way.

Start from the data, not the screen

The first artefact I write is not a component. It is the shape of the data — what entities exist, what owns what, and which direction information flows. Screens are a projection of that. If you design the screen first you end up with a data model shaped by layout accidents, and every new feature fights it.

Decide what is allowed to be slow

Not everything needs to be fast. Some things need to be fast, and everything else needs to be correct. Naming which is which early stops you from optimising a nightly job while a hot path does three round trips.

Make deployment boring before you need it

• ›One command should bring the whole stack up locally.
• ›The production path should differ from local in configuration only, never in structure.
• ›If a deploy requires a human to remember a step, that step is a future outage.

A system you cannot rebuild from scratch is a system you do not fully understand yet.