Three Lock Box: secure construction finance and escrow software

Construction projects are notoriously prone to payment disputes, opaque workflows, and mountains of paperwork. Project owners, contractors, subcontractors, and lenders often lack a single source of truth for commitments and disbursements, creating costly delays and eroding trust between parties. Three Lock Box set out to change this with a fully digital, secure escrow and payment control environment purpose-built for the construction sector.

Holding other people’s money in escrow changes the engineering requirements in ways that a normal CRUD application never has to contend with.

A payment is a state machine, not a record. A draw moves through requested, certified, approved, funded and released, and different parties hold the authority to advance it at different stages. Conditional release means the platform has to encode which conditions apply to which draw, evaluate them, and refuse to advance when they are not met — rather than leaving that judgment to whoever happens to be looking at the screen.

Every figure has to be explainable after the fact. When a dispute surfaces six months later, the question is never just “what is the balance”. It is “how did it get there, who approved each step, and what did they see at the time”. That means an append-only history rather than mutable records: a corrected certification is a new event that supersedes the old one, not an overwrite that erases it.

Documents are part of the transaction, not attachments to it. A lien waiver is not a file someone uploaded; it is evidence tied to a specific payment to a specific party for a specific scope of work. The link between the money and the paperwork is the entire point, and it has to survive the project it belongs to.

Different parties must see different truths of the same project. A lender needs disbursement status and remaining commitment. A subcontractor needs to know whether their invoice cleared. An owner needs the whole picture. A title company needs the waiver chain. One dataset, four legitimate and quite different views of it — which is why transparency here means role-appropriate visibility, not simply showing everyone everything.

MongoDB over a relational store. The instinct for a financial system is a relational database, and for the ledger itself that instinct is right. But construction projects have no stable shape: a residential build with one lender and three subcontractors and a hospital expansion with staged financing, dozens of trades and a title company share almost no structure. Modeling that relationally means either a table with many nullable columns or an entity-attribute-value design that is painful to query. A document model represents each project as it actually is. The trade-off is real — the schema discipline a relational store enforces for you has to be enforced in application code instead, deliberately rather than by default.

Razor Pages over a single-page front end. A React or Angular front end would have been the fashionable choice and the wrong one here. This platform is used by construction professionals, on site, on whatever device and connection they have, for tasks that are form-driven rather than interactive. Server-rendered pages load faster on a poor connection, keep the security-sensitive logic on the server, and remove an entire build pipeline and API contract from a small team’s maintenance burden. What we gave up is the fluid, app-like interaction model — which this audience was not asking for.

A separate .NET Core API layer. The page layer and the service layer were kept distinct even though Razor Pages does not require it. Escrow logic is the part of this system that must be tested exhaustively, and it is far easier to test a service boundary than a page handler. It also means the same logic can be driven by something other than a web page later — a lender integration, a mobile client — without being rewritten.