Your React app has several hand-rolled useReducer state machines for wizards and async flows. When does moving them to a statechart library such as XState pay for itself, and when is it over-engineering?

## What a hand-rolled reducer machine gives you already A `useReducer` with a state-first transition function already delivers most of the value people attribute to state machines: a named set of states, transitions decided by (state, event), illegal transitions ignored, and a pure function you can test without rendering anything. That baseline is cheap and it belongs in the codebase whether or not you ever adopt a library. The question is what a statechart adds beyond it. ## Pressure one: hierarchy A statechart's defining addition over a flat finite state machine is *nested* states. In a flat model, a three-step wizard where each step can be editing, validating or submitting has to name every combination: `step1Editing`, `step1Validating`, `step1Submitting`, `step2Editing`… The list grows as steps times sub-states, and every transition that applies to "any validating state" has to be written once per combination. Hierarchy lets the sub-machine be defined once and reused inside each step, and lets a transition attached to the parent apply to all its children. This is the single clearest signal. If you catch yourself writing state names that are two concepts glued together, you have hit the ceiling of a flat model. ## Pressure two: concurrency A single `status` field expresses exactly one thing at a time. When a screen has genuinely independent concerns in flight — an avatar uploading while the profile form is still being edited — a flat machine either invents combined states or, more commonly, quietly grows a second field beside the status and you are back to flags that can disagree. Statecharts model this as parallel regions: two orthogonal sub-machines, each with its own current state. You can approximate it with two reducers, and for two regions that is often the right call; past that the coordination between them is the thing you are hand-writing. ## Pressure three: repeated machinery Count what your reducers re-implement. Guards on transitions, delayed transitions ("if still submitting after five seconds, show the slow-network hint"), actions that must run on entering or leaving a state, retry with a bounded count. Each is a dozen lines the first time and a maintenance surface every time after. A library ships these as first-class concepts with one semantics instead of five slightly different in-house ones. ## Pressure four: the flow as a shared artifact Statecharts can be rendered as diagrams, and a definition that is data can be inspected by tooling. That matters when the flow is a product surface that a designer, a QA engineer or a compliance reviewer needs to reason about — onboarding, payments, KYC. "Here is the diagram, is this the intended behaviour?" is a conversation you cannot have over a nested `switch`. If nobody outside the team ever needs to see the graph, this benefit is worth nothing to you. ## The costs, stated honestly A statechart library is a second mental model beside React's own. Engineers who are fluent in hooks are not automatically fluent in statecharts, and half-learned adoption produces machines that are harder to read than the reducers they replaced. There is a bundle cost. There is the migration cost of flows that work today. And there is a subtler one: React still owns rendering and effects, so the machine's side effects have to be integrated with React's effect model rather than escaping it — the library does not exempt you from the Rules of React, and a machine that mutates or triggers effects during render is broken in exactly the same way a component would be. ## How I would actually decide I would not migrate a codebase wholesale. I would name the criteria — nested states, parallel regions, more than roughly a dozen transitions, or a flow that stakeholders outside engineering review — and adopt the library only for flows that meet them, keeping plain reducers for the rest. Then I would look after six months at whether the adopted machines are being maintained by more than the person who wrote them. A pattern that only one engineer can safely change is a liability regardless of how correct it is. The failure mode worth naming out loud is adopting the library and still writing a flat machine in it: you pay the learning curve and the bundle and get back what a `useReducer` already gave you.