Approve the run. Hold the one payout that shouldn’t go.
Ferrow, payout approvals for finance teams. Designed end to end, shipped as a prototype that runs.
- Scope
- Flow, identity, system, product
- Platforms
- Web and iOS
- Built on
- shadcn/ui, Geist, React
- Deliverable
- Figma and a working prototype
One changed bank account, hidden in 148 payouts.
It showed up as row two of a table, at the same weight as the other 147. Approvers reviewed everything, so they reviewed nothing.
148 payouts. One of them changed.
Northwind Logistics · $18,420.00
Human steps, down from 10
Tool, down from three
Screens mapped, web and mobile
Decision for 147 unchanged payouts
Ten steps, three tools, zero warnings.
Walked as it really happened. A red pin wherever an approver lost the thread.
- 1Context lost at the door
- 2Everything weighs the same
- 3All or nothing
- 4The review leaves the product
- 5The one signal was hidden
Five places where two good requirements collided.
None of the hard parts were visual. Each one was decided before a screen was drawn.
Cooling period vs Friday payroll
Isolate, never block. The batch goes; the changed payee waits.
One approval record vs 147 good payouts
Split, don’t untick. Held rows become a linked child batch.
Controls vs approver fatigue
Show what changed first. Everything else is one line.
Dual control vs an approver away
Delegate before the absence. Time-boxed and logged.
Approving on a phone vs approving blind
Mobile approves the unflagged, never the flagged.
The run is only as slow as its one real exception.
Seven steps, one tool. Every fix answers a red pin.
- 1Arrives in context
- 2Weight follows risk
- 3Split, not all or nothing
- 4The check stays in the product
- 5The signal is computed
Bank detail change, with a 72-hour cooling period
45 screens mapped across web and mobile
A treasury product that keeps its nerve.
White and soft slate, one verdigris that means “ours”, and amber for the payout that waits.
The F is a batch.
Stem, batch, payouts, and the one square held back.
Five ways to approve a batch with one bad payout in it.
Same data, same components. They differ in structure, never in styling.
B · Exception first
The held payout rises above the batch, old and new account side by side. Release only ever counts what is ready.
shadcn/ui, with a different temper.
Every Ferrow token is a shadcn/ui token first. Drag to switch the theme.
Every flow wireframed, with the real copy.
Drag the boards. Nothing in hi-fi had to rewrite a word.
One run, from review to settled.
Direction B through the whole run. Every number matches the prototype to the cent.
Close up
Approve between meetings. Verify at your desk.
Face ID to release. The dock turns into the approval status, so nothing on the screen moves.
A bank detail change, checked and held
Six exceptions become a queue
Controls and the states nobody scopes
A prototype that runs, not a mockup that clicks.
Real shadcn/ui components and Ferrow tokens. Every video on this page is the prototype, recorded at 60 fps.
Routes, from the inbox to the audit log
People to switch between
Scenarios, empty to partial failure
Payouts, $412,380.00 to the cent
A launch page built from the product.
Real screens, real components. Keep scrolling.
Three assumptions that need evidence.
On the prototype, with finance operators, with tasks rather than opinions.
The queue threshold
Is five exceptions where approvers lose track, or three?
The mobile limit
Do approvers accept desktop-only verification, or work around it?
The call-back step
Does the call get made under Friday pressure?
Have a workflow where one row decides everything?
We redesign the path to the action and hand it back as a working prototype in five days.