Zustand.

Where Zustand fits on a long engagement.

Zustand occupies the space between component state and a full state container. It handles genuinely shared state without actions, reducers or a provider, which for most applications is the right amount of structure. The selector model means a component re-renders only when the slice it reads changes.

What it deliberately omits is the traceability Redux provides. There is no action log to replay, so understanding how the application reached an unexpected state is harder. On a product where support needs to reconstruct user sessions, that omission is the deciding factor rather than a detail.

What an assigned team does with Zustand.

Minimal libraries put the structure on the team rather than the tool. Without enforced conventions a codebase grows several stores with overlapping responsibility, which is cheap to prevent by agreement and expensive to untangle later.

Agreeing those conventions early and holding them is exactly the kind of thing that benefits from the same people staying on the codebase, as set out in how an assignment runs.

What we use Zustand for.

• Shared state without ceremony Cross-component state where a full container is more structure than the problem needs.
• Avoiding unnecessary re-renders Selector subscriptions so a change to one slice does not repaint unrelated parts of the tree.
• Incremental adoption Introduced one store at a time in an existing application, with no provider restructuring.

How Zustand capacity is assigned.

Zustand work sits inside frontend capacity under outsource software development services, with store conventions agreed at the start rather than discovered.