Backflip · Real estate lending

Rebuilding the system we were renting

Budgets came in as spreadsheets. Everything after closing, from the budget ledger to the borrower’s draw requests to our servicing and accounting review and the disbursement itself, ran on a third-party platform we paid heavily for and couldn’t change. We rebuilt all of it in two stages and retired the vendor.

• Draw payout cut from 3.5 to 2.1 business days, 40% faster
• Third-party draw platform retired; budgets, draws, and disbursement now in-platform
• About $275K a year in vendor fees eliminated

Role

Senior Product Manager, then Head of Product · Q1–Q3 2026

Scope

Product strategy, borrower and internal experience, cross-functional facilitation with servicing and accounting, vendor migration and cutover design

Worked with

Loan ops (pre-close and servicing), design, engineering, sales, finance and accounting, capital markets

Timeline

Three quarters: a larger build, big process changes, and a full migration

The problem

Backflip lends against renovation projects, so a loan is really a budget: a line-item plan for the work, drawn down in stages as the work gets done. When I arrived, that budget arrived as a spreadsheet attached to an email. Underwriting parsed it by hand. Every version was a new attachment, and the deal waited while somebody reconciled them.

After closing it got worse, in a more expensive way. The budget ledger, the borrower’s draw request experience, and our servicing and accounting teams’ review and disbursement workflow all lived on a third-party platform. We paid a great deal for it, and none of it was ours to fix. When servicing wanted a different review step, or a borrower found the request flow confusing, the answer was a support ticket to a vendor.

That matters more in this market than it sounds. Draw turnaround is one of the few things a real estate investor actually shops on — the money has to arrive before the next phase of work can start. It was a competitive lever we did not control.

Stage one: budgets, before the loan closes

We started upstream rather than at the expensive part, deliberately. Letting borrowers submit a structured budget against their project as part of underwriting was smaller, shipped sooner, and paid off immediately: the spreadsheet round-trip disappeared from the critical path, and the same structured budget became the object everything downstream could be built on. Turnaround improved, and time to close came down with it.

Building the ledger first would have been the obvious order. Building the intake first is what made the ledger cheap.

Stage two: the draw system, end to end

The second stage was the one that retired the vendor. It had two faces and both had to be good, which is the part that makes draw management harder than it looks:

• The borrower experience. Requesting a draw against budget line items, with the state of the request legible without emailing anyone to ask.
• The internal review. Servicing reviewing and approving against the budget, and accounting handling the disbursement — built with those teams rather than handed to them.

Bringing accounting into the design early was what kept the general-disbursement side from becoming a second manual process bolted onto a shiny borrower-facing one. The end state was one system where a draw moved from request to payout without leaving the platform.

Retiring the vendor without disrupting live loans

Cutover was its own problem: draws were live on real deals with dozens more in flight at every stage of completion. Move everything at once and you disrupt borrowers mid-project; leave everything and you pay for two systems indefinitely.

I ran a working session with the engineering, ops and servicing leads and the ops lead who owned draws day to day, rather than deciding it in product and socializing it afterward, and we landed on a completion-percentage threshold: loans under 50% complete migrate; loans at or above 50% finish their remaining draws on the legacy vendor. The logic was concrete rather than arbitrary: a loan under 50% has been through one or two draw cycles and moves cleanly, while a loan past 50% is deeply embedded in borrower and ops workflow.

The piece that made it a plan rather than a preference was the trigger condition: no new loans go on the old system once engineering finished its final workstream. That bounded the dual-system period instead of leaving the retirement date to drift.

Tradeoffs

Rebuilding a vendor system is the expensive answer by default, and it is usually the wrong one. It was right here because the vendor sat on three things at once, the ledger, the borrower experience, and a competitive lever, and because the fee, about $275K a year, was large enough that the build paid for itself rather than merely feeling better.

The threshold cutover also accepts a real cost: a set of borrowers finished their loans on the old platform and never saw the new one. That was the price of not disrupting deals mid-project, and it was bounded, which is the only reason it was acceptable.

What I’d do differently

Cut scope sooner. The early part of the project was slow and took several build iterations, and the cause was that I was trying to fix the operators’ workflow problems at the same time as the infrastructure and borrower experience we actually needed. Mid-project I made the cut: focus on the infrastructure, the borrower experience, and the migration tooling, and pause the internal ops systems. The right MVP was always the highest-value thing, getting off the vendor, and I should have defined it that narrowly from the start instead of spending early resources on the adjacent ops efficiency.