Live cash-position view
One server-rendered screen replacing three exported spreadsheets.

A server-rendered treasury console replacing the spreadsheet round-trip between finance, banking partners and the CFO's office — one live cash position, no export dance.
Start a Project
Finance, the banking desk and the CFO's office each kept their own export of the same accounts and reconciled them by hand every morning. Any disagreement was settled by whoever trusted their spreadsheet more — not by a system of record. The company's cash position was, functionally, a rumor that got re-confirmed daily.
We started with a week of shadowing the morning reconciliation ritual itself, not the accounts it was reconciling — the actual failure was procedural, not numerical. From there the build was sequenced around one rule: nothing ships that produces a second export. Every screen reads from the same server-rendered source, so there is structurally only one place a number can come from.
A server-rendered treasury console with role-scoped views for finance, banking operations and leadership, account balances rendered on the server so the page is current the moment it opens, and a shared component layer the team now extends without redesigning each screen.


One server-rendered screen replacing three exported spreadsheets.
Finance, banking ops and leadership each see the view scoped to their job.
Balances render on the server, current the moment the page opens.
Every balance is traceable back to its source account, not a pasted figure.
New views extend existing components instead of forking a new screen.
A summarized read for the CFO's office that still traces to the same source.


The client-side architecture and interface layer shipped for this engagement.

Services, APIs, and business logic running the system end to end.

Datastores and pipelines chosen for this engagement's consistency and throughput needs.

Deployment, orchestration, and delivery tooling running the platform in production.
Current balances without hammering banking APIs
Partner banking APIs rate-limit aggressively. We built a server-side cache with per-account invalidation so a live-feeling view never means a live request per pageview.
Role-scoped views without duplicating the data model
Finance, banking ops and leadership needed different slices of the same accounts. Row-level scoping in the query layer meant one schema, not three divergent view models.
Keeping a shared component layer from calcifying
Early treasury dashboards ossify into one-off screens. Components were built against a documented prop contract from the first screen, not extracted retroactively from the third.
1 week
Shadowed the morning reconciliation ritual before scoping anything.
2 weeks
Server-rendering and role-scoping decided before a screen was drawn.
2 weeks
Three role-scoped flows wireframed against real account data.
6 weeks
Shared component layer built alongside the first three screens, not after.
2 weeks
Load-tested against month-end volume, the desk's actual worst case.
1 week
Parallel-run against the spreadsheet process for one full close cycle.

“We finally have one number everyone agrees on before the CFO asks for it, not after.”
Elena Kovač · Director of Platform · Meridian






Technical briefingNot a sales desk