Yeah I find they're best kept small. I find them useful in managing GUI state. Some business logic gets a bit too complicated to nicely represent in a state machine.

You could have the calling function do the state transitions all in one place. The individual state functions would still do most of the work and generate the information required to determine the next state. But they would be "unaware" that they're part of a state machine.

I tends to have a config part where all possible transition are listed in a type safe way. ( error transition as well. Basically what is not desribed there is a bug or a unknown error transition )

I also tends to have state machine calling other machine or being composed of 2-3 smaller ones.

I save the state in some serialized form in DB if needed.

It’s great for customer flow : like; tracking where they are in the KYC process or onboarding and deciding what to do next.

Without having 50 nested switch statement.

The part that specifies "which transitions are possible and which are not" (more precisely: which state results from a given state and input) -- known as the state-transition function [1] -- is a necessary component of the state machine definition. If you don't have that, you don't have a state machine in code; you just have a bunch of functions.

[1] https://en.wikipedia.org/wiki/Finite-state_machine#Mathemati...

> What I don't like about state machines in code is that transitions become less obvious the bigger the state machine gets.

There are techniques to keep those large state machines manageable, such as structuring them with sub-state machines.