State management for small teams

Teams tend to reach for this after something has already gone wrong. Most advice about state management assumes a team that does not exist at your size. Here is the version that does not.

Code gets read far more often than it gets written, and usually by someone with less context than the author had. It is worth deciding this deliberately rather than inheriting whatever the last person set up.

What to keep

Most apps need far less shared state than they end up with. None of that requires a large budget, only a decision and someone to own it. The practical test is whether someone new to the project could tell, in a minute, that it had been handled.

What to drop

Process that exists to coordinate ten people is overhead when there are two of you. It is worth being explicit about, because assumptions differ quietly.

Where to start

Every duplicated piece of state is a future bug. This is the sort of thing that compounds, quietly, in both directions. It is worth deciding this deliberately rather than inheriting whatever the last person set up.

How to tell if yours is fine

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
• Every duplicated piece of state is a future bug — and you know whether that is true here
• There is a way to tell whether the last change to this helped

If you want a second opinion on how yours is set up, ask.