SaaS Products
EQTY
Situation
An operator moving money under load had to jump between trust cues, ledger actions, and approval workflow as if they were three products. EQTY needed one operating model that could extend to new financial modules. Existing separation of layers made every new surface reinvent permissions, money states, and language.
My mandate
Critical decision
Situation
Decide whether trust, ledger, and workflow stay separate product layers or become one operator model with shared entities and states.
Options considered
Three product surfaces with shared branding
Would keep duplicate onboarding, permissions, and money-state language — the original fracture.
One monolithic screen for all financial work
Would overload operators and block modular extension when a new financial surface joins the OS.
Shared operating model: entities, permissions, money states, approval rules as one system
Observation
Early mapping showed the same people and money states reappearing across trust, ledger, and workflow with inconsistent language. Separate layers forced operators to reconstruct the system mentally under load.
Insight
A shared model slows shipping a single module in isolation — but prevents three products that cannot share approvals or trust later.
Response
Design one module set for how money, people, and decisions move, with trust visible in the interface and workflows tuned for clarity under load.
Result
New financial surfaces can join the OS without fracturing the operator experience. Directional while the product is still in founding build.
How the system changed
Mapped the fragmented starting point: trust, ledger operations, and workflow as separate layers.
Proposed shared entities — people, permissions, money states, approval rules — as the spine every module attaches to.
Designed operator workflows with fewer dead ends and language that matches how finance teams work.
Kept the visual system quiet so hierarchy and structure can carry growth without seasonal redesign.
Outcome
organisational
Trust, ledger, and workflow extend as one system instead of three separate products.
operational
Experience architecture decided with product, not applied after modules locked.
organisational
Future modules attach to the same entities and states rather than inventing a parallel stack.
Frames
What I would change now
Publish one end-to-end operator scenario with before/after entity maps as the primary hiring-manager evidence, and keep abstract OS language only as captions on that workflow.
Have a similar challenge?