One hard-coded approver did not survive the second customer

The first customer had one approver, hard-coded. The second had a hierarchy, and the request arrived as a bug about their approvals being wrong.

Branching per customer works today and compounds forever: every fleet adds a branch, none can safely be removed, and nobody can answer "what are this customer's rules" without reading code.

The rule underneath was not about approvals at all. A customer's hierarchy, spending authority and chart of accounts are their operating procedure — they change without asking us, so they belong in configuration, not in a release.

Getting that right meant sitting with operations, purchasing and finance staff to find the real rule before specifying anything.

• An approval engine the business configures itself: sequential and parallel ladders, per-approver spending authority, mandatory price checks, guards above a budget owner's limit, and super-approver override.
• Bypass states rendered honestly. When a ladder is short-circuited the screen says so, because a trail that hides its own exceptions is worse than no trail.
• Specification and decision records first, then implementation across shared contracts, the API, the dashboard and the app — one change landing coherently across four surfaces instead of four drifting.

customer organisations on their own hierarchies

3customer organisations on their own hierarchies

open design questions resolved

50+open design questions resolved

to rebuild it

< 3 weeksto rebuild it

escalations handled directly

100+escalations handled directly

Named decision owner on the decision records. Every customer since has configured their own hierarchy without a code change.

• NestJS
• Next.js
• React Native
• MySQL
• TypeScript
• shared contracts