There are parts of your product where you compete. And parts that are just infrastructure.
In the early days at Fig, a vendor owned the part where we compete.
We built our first Loan Origination System on top of a vendor platform. The approval API (the single most important operation in our business, the moment an applicant finds out if they qualify) took 30 seconds end to end. We treated that as an engineering problem. We ripped it apart, rewrote what we could, hardcoded optimizations wherever possible. The best we got it to was 14 seconds.
Fourteen seconds was the ceiling. Not because the calculation was complex. Because the vendor's infrastructure had a floor we couldn't engineer through.
That's when we stopped treating it as an engineering problem and recognized it as a strategic one.
First: the LOS vs LMS distinction
Most people outside lending use "loan software" as one category. It isn't.
The LOS (Loan Origination System) is everything involved in booking a loan: prequal, KYC, bank linking, agreements, consents, pricing, risk decisioning, partner integrations. This is where a lender competes. It's your conversion funnel, your applicant experience, your fraud surface, your speed to market on new products.
The LMS (Loan Management System) is everything after a loan is booked: servicing, credit reporting, accounting, collections. Important, but largely commoditized. The differences between vendors are real but not where you win.
We were running our LOS on a vendor platform that wasn't built for the speed we needed. Every origination feature ran through that vendor's API. Every UI change required going through an offshore team maintaining the vendor customizations. Every performance improvement had a ceiling we couldn't engineer past.
The LMS was fine to leave on vendor infrastructure. The LOS was not. Owning the origination experience was our job.
The economics
Vendor licensing fees for the LOS were substantial and scaling linearly with our loan book. As we grew, costs grew proportionally. There was no operating leverage in the model.
The number that made the case viscerally in an internal presentation: our entire engineering infrastructure (everything we ran ourselves) cost under $20,000 a year. The LOS vendor alone cost multiples of that monthly.
Projected savings from rebuilding in-house ran into the millions over a three-year horizon. That projection also enabled something unexpected: we were approaching a contract renewal with this vendor. Going into that negotiation with a credible in-house alternative gave us real leverage. We came out with a much better contract.
Optionality has real value. Sometimes before you've even exercised it.
Why it was buildable in a quarter
The question we got most often: how do you rebuild a production loan origination system in three months?
The honest answer: we knew exactly what we were building.
Years of running the system meant the spec was already written. The underwriting rules, the decisioning model, the product structure, the edge cases in a regulated lending flow: all of it was understood. What the team brought to the rebuild wasn't just engineering capacity. It was earned knowledge of a complex domain. That's what compressed the timeline.
We ran a POC first. Evaluated the new frontend stack, tested the integration patterns, confirmed the approach before committing the team. The active build phase after that was roughly one quarter.
Three decisions made it fast:
We kept the LMS integration. Rather than replacing everything at once, the new LOS synced loan data to the existing LMS at the booking step. One clean handoff point. No big bang migration.
We scoped ruthlessly. Some existing features didn't make the initial launch. They shipped the following quarter. Hitting the deadline mattered more than shipping everything. The hard deadline was driven by the vendor contract renewal timeline. We couldn't enter that negotiation still fully dependent on the product we were trying to replace.
The business logic was the spec. We weren't doing product discovery. The old system told us exactly what the new one needed to do. Most of the engineering effort was integration work, not definition.
What changed after launch
Prequalification API: 14 seconds to 1.5 seconds.
The team could ship origination features without going through an external vendor's release cycle. New product types, which would have required significant vendor customization and additional licensing, became internal engineering projects.
The offshore team that had been maintaining the vendor customizations was no longer needed for the origination layer. That dependency dissolved on its own once the thing it was maintaining was gone.
And the contract we signed at renewal reflected the fact that we no longer needed everything we used to.
The principle
For every part of your product, ask: is this where we compete, or is this commoditized infrastructure?
Where you compete, own it. Vendor lock-in in your competitive surface area compounds across cost, performance, velocity, and negotiating position. The 14-second prequal wasn't just a bad user experience. It was a constraint on everything: conversion rates, product iteration, the credibility of our roadmap.
Where it's commoditized, buy it. The LMS stayed on vendor infrastructure. That was the right call. The right answer isn't always build.
The LOS vs LMS distinction matters because it forces you to be explicit about where you're competing. Most teams never draw that line. They end up either over-building infrastructure that doesn't differentiate them, or under-investing in the surfaces that do.
Draw the line early. Own what's on the competitive side of it.