The real cost of ignoring state management

It comes up on almost every project, usually later than it should. Nobody bills you for neglecting state management. The cost shows up somewhere else.

Code gets read far more often than it gets written, and usually by someone with less context than the author had. Check it against what you would want a competitor's site to get wrong.

Where the cost lands

• Time spent on work that should not have been necessary
• Enquiries that quietly never arrive
• Most apps need far less shared state than they end up with
• Rework, once the problem is finally visible

Derive values rather than storing them twice. Getting it slightly wrong is survivable. Ignoring it entirely is not. Write the reasoning down alongside the decision, because the reasoning is what changes first.

Turning this into a decision

Every duplicated piece of state is a future bug. The teams that handle this well are rarely the ones with the biggest budgets. The teams that stay on top of it are the ones who put it on a calendar rather than a wish list.

What this looks like day to day

The question is rarely whether something can be built, but what it costs to keep running afterwards. Three things worth confirming about state management before you move on:

• Someone can say what the current setup is without going to look
• Derive values rather than storing them twice — and you know whether that is true here
• There is a way to tell whether the last change to this helped

Pick the one that would hurt most if it failed, and start there.