← Devlog

May 12, 2026 · 159 views

Turning messy vendor onboarding into a clean state machine

If-else spaghetti was hiding real bugs. A state machine made approvals boring — in a good way.

Vendor onboarding started life as a pile of if-else. Is the vendor submitted? Approved? Rejected? Waiting on docs? Re-submitted after rejection? Each new case added another branch, and the branches started disagreeing with each other. Classic. The bugs were all the same shape: a vendor ending up in a state that shouldn't exist. Approved but with missing documents. Rejected but still editable. The logic technically allowed it because nobody had drawn the actual map. So I drew the map. I modeled onboarding as a proper state machine — a fixed set of states and only the transitions that are legal between them. "Rejected" can go back to "Under Review", but it can't jump straight to "Approved". If a transition isn't on the map, the code simply refuses it. That one change killed a whole category of bugs, because the impossible states became literally impossible to reach. Then I added bulk actions on top — approve or reject dozens of vendors at once — which was only safe because every vendor was guaranteed to be in a known state. No surprises hiding in the batch. Onboarding went from "exciting" to boring and predictable. For an approval workflow, boring is the highest compliment you can give it.