Soldo.
Spend controls are only useful if they hold at the moment of purchase.
- Client
- Soldo
- Sector
- Fintech
- Scope
- App + web
- Stack
- TypeScript, Node.js, React
A spend management product on app and web, covering cards, budgets, approvals and expense reporting.
What made it hard.
Ledgers must balance to the cent across providers, currencies and retries. Approximate is the same as wrong.
Onboarding compliance
KYC and AML checks have to satisfy regulation without becoming the reason users abandon signup.
Provider dependency
Payment rails fail in ways you do not control. The system has to degrade without losing money.
Audit expectations
Regulators ask what happened on a specific date to a specific account. The answer has to take minutes.
What we shipped.
A spend management product on app and web, covering cards, budgets, approvals and expense reporting.
How it holds up.
Double-entry from the first commit, idempotency on every money-moving endpoint, and a reconciliation job that runs whether or not anyone is watching.
The systemAuthorisation rules are evaluated server-side at transaction time rather than enforced in the interface, so no client can bypass them.
Theirs, from day one.
Repositories, cloud accounts and documentation sat with the client throughout. Senior engineers wrote the production code rather than specifying it.
Ask for the full metrics on a call →More fintech work.
All 42 case studies →Building something like Soldo?
Tell us what you are building. A senior engineer replies within one business day. NDA on request.