Olatunde Success on designing escrow-backed transactions twice, for Dbrij’s milestone-funded project management and Resikonet’s rental platform, and the engineering patterns that make escrow trustworthy.
I have now built escrow twice in production: once for Dbrij Projects, where clients fund project milestones into bank-held escrow, and once for Resikonet, where rental payments sit in escrow until both tenant and landlord are protected. Different domains, same lesson. Escrow is less about moving money and more about state machines people can trust.
Escrow is a state machine
Every escrow transaction is a strict lifecycle: funded, then locked against acceptance criteria, then released or disputed. The engineering discipline is making illegal transitions impossible, not just unlikely. In Dbrij, acceptance criteria are locked at funding time; neither side can quietly rewrite the deal after the money is committed. Approved work releases payment automatically. No human in the happy path means no human to pressure.
The three non-negotiables
Idempotency keys on every money-movement endpoint. A retried webhook or a double-tapped button must never move money twice.
Append-only audit logs. When a dispute happens, the log is the ground truth both sides can be shown.
Reconciliation jobs. BullMQ workers continuously compare internal state against provider statements, because the bank’s truth and your truth will drift.
Disputes are a feature, not an exception
On Resikonet we paired escrow with a Trust Score reputation system and structured dispute resolution. The insight: users do not expect zero conflict. They expect a fair, legible process when conflict happens. Escrow without a dispute path is just a delay on the same old fight.
If your product’s core problem is two parties who do not trust each other, an escrow engine is often the honest answer. Build it as a state machine, log everything, and make the dispute path as polished as the payment path.
