AI is the new variable in the classic build-vs-buy debate and it tips the scales more decisively than anything that came before.
A software development agency just presented you with a quote. They will build you your dream loan origination software using AI for a fraction of what was possible a year ago.
The number is $250,000. That's what it would cost, they say, to build a loan origination system from scratch. Six months, four engineers, full ownership of the codebase. No vendor lock-in. No licensing fees. No sales rep calling every quarter to upsell you on a module you don't need.
You run a quick mental comparison against a vendor quote: $100,000 a year, forever. Two and a half years of licensing fees and you've paid for the whole thing. Maybe you can license it to another lender. Maybe you can sell it. The important thing is you'd own it. There's something deeply satisfying, in American business culture, about owning the thing.
The decision makers are private lenders, not software developers. They’re sharp but they’ve never done this before so chances are they’re going to severely underestimate what it takes.
The build-vs-buy debate in enterprise software is old. It predates the internet. It predates the personal computer, technically, if you want to go back far enough. The question, “Do we make this thing ourselves, or pay someone else who already made it?”, is as fundamental to business as the question of whether to grow your own wheat or buy it from a farmer.
For most of the history of lending software, the debate resolved itself in reasonably predictable ways. Small shops bought. Large banks with armies of developers and the regulatory complexity to match sometimes built. And in the middle, the regional lenders, the specialty finance companies, the insurgent fintechs, argued about it in conference rooms for years and often ended up doing some version of both, which is another way of saying they satisfied nobody and maximized their technical debt simultaneously.
What changed everything wasn't a new vendor, or a new regulation, or even a new kind of loan. What’s different now is that we have AI.
The new arithmetic
Here's what the software development agency probably has in their model: AI-assisted development has collapsed the cost of writing software by somewhere between 30 and 70 percent, depending on who you ask and what you're building. Code that used to take a week takes a day. Tests that used to require a dedicated QA team can be generated automatically. Documentation, scaffolding, boilerplate and all the unglamorous majority of any software project happens in minutes.
This is unambiguously good news for the build side of the ledger. What might have cost $3 million is now possible with $1 million. The eighteen months might be six. The case for building has gotten materially better.
But here's the thing about efficiency improvements: they don't just help you. They help everyone.
The same AI tools that are making your in-house or your development agency’s engineers faster are making your vendor's engineers faster. A lot faster. And your vendor's engineers, unlike your in-house or your agency’s, are working on nothing but loan origination software, all day, every day, for years. They have a codebase with thousands of edge cases baked in. They have a customer success organization that has absorbed the product feedback of hundreds of lenders who each discovered, the expensive way, what their first version got wrong.
So yes, building has gotten cheaper. But buying has gotten dramatically better.
A note on the math: The real cost of a custom-built system is almost never what the initial estimate says. A study of enterprise software projects found that nearly 70% run over budget, and the average overrun is 45%. More importantly, those numbers don't include the ongoing cost: the engineers who maintain it, the compliance updates when regulations change, the integrations that break when a third-party API changes its schema. Build costs are a down payment. Maintenance is the mortgage.
The question nobody asks
There's a famous line, attributed to various people over the years, about how the definition of insanity is doing the same thing over and over and expecting different results. Lending companies evaluating build-vs-buy have been doing something structurally similar: asking "can we build this?" when the more important question is "should we?"
Michael Burry, before he became famous for betting against the housing market, spent years as a doctor. What made him unusual as an investor wasn't just his willingness to be contrarian. It was his discipline about which bets deserved his attention in the first place. He wasn't looking for companies to bet against. He was looking for the specific, narrow cases where the market had gotten something structurally wrong.
The same discipline applies here. The question isn't whether you can build a loan origination workflow. You can. The question is whether building one gives you something durable, something that compounds, something that a competitor using a commercial platform cannot replicate. Something that justifies the cost and the distraction of maintaining it forever.
For most lenders, for most of the capabilities they need, the honest answer is no.
This is not a popular thing to say to the software development agency that presented you with a quote or your in-house engineers. Engineers, by temperament, prefer to build. There is something deeply unsatisfying about paying a vendor to solve a problem you know you could solve yourself. It feels like intellectual defeat. It isn't.
Warren Buffett has a concept he calls the "circle of competence." The idea is simple: know what you're good at, and stay inside it. Don't invest in industries you don't understand. Don't try to be all things. The companies that consistently win, he argues, are the ones that understand precisely where their edge ends and their amateur hour begins.
For a lender, the circle of competence that actually creates value is almost never "writing software." It's the thing that allows them to close quickly. It's the distribution channel that reaches the borrowers your competitors can't reach. It's the loan structure that solves a problem for a specific type of borrower in a way that existing products don't.
None of those things require building your own loan management system. In fact, building your own loan management system actively pulls engineering resources and organizational attention away from the things that do matter.
Where it actually gets interesting
There are exceptions.
The interesting cases are the lenders who have built something that genuinely constitutes an edge. Not "we wanted control of the roadmap" (everybody says that; almost nobody means it in a way that creates value). Not "we didn't want vendor lock-in" (you have vendor lock-in; you're just locked into yourself). The real thing.
A lender who has spent five years building a proprietary underwriting model trained on their own loss data, with input features that no data provider sells and no vendor platform natively supports — that lender has a real argument for owning the decisioning layer. Not the whole stack, necessarily. But that piece.
A marketplace lending platform where the borrower experience is architecturally inseparable from the product thesis — where the interface isn't just nice to have, it's the product — has a real argument for building that surface. Not the servicing engine underneath. But the part that touches the borrower.
The pattern, if you look carefully, is always the same. The lenders who build successfully aren't the ones who decided that building was philosophically preferable. They're the ones who identified a specific, narrow thing that vendors can't or won't build for them, and built exactly that. Everything else, they bought.
The lenders who get this right aren't choosing between building and buying. They're choosing exactly where the boundary sits between the two.
The trap with a friendly name
AI has created a new version of an old trap. It has a friendly name. It's called "it's so easy now."
Because building has gotten cheaper and faster, the temptation to build things you don't strictly need to build is higher than it's ever been. The friction that used to act as a natural filter — the sheer expense, the months of delay, the engineering bandwidth cost — has been reduced. And so companies build more. They build features that would have been vendor purchases three years ago. They extend the custom codebase into territory that doesn't need to be custom. And then, six months later, they discover that "easy to build" and "cheap to maintain" are not the same sentence.
The ongoing cost of a custom system is almost entirely unaffected by how cheaply it was built. Every line of custom code is a liability that needs to be fed: updated when dependencies change, fixed when edge cases emerge, understood by the next engineer who inherits it. The AI that made it cheap to write doesn't make it cheap to maintain. That's still humans, doing the work, every quarter, forever.
Back to that vendor who quoted you $250,000. Let's say they build it. Let's say the project comes in close to budget — call it $300,000, which would be an unusually good outcome. Eighteen months later, they have a loan management system. It does what they designed it to do.
And then the work begins.
A new state passes a regulation that changes how delinquency notices have to be delivered. That's an engineering ticket. A payment processor changes its API. That's two engineering tickets. A bank integration breaks on a version update nobody expected. That's a three-day incident. The compliance team needs a new report format for an investor. That's a sprint item that knocks something else off the roadmap.
None of these things are dramatic. None of them individually break the business case. But they accumulate, year after year, into something that looks a lot like what the vendor was going to charge. Except the vendor, unlike the engineering team, does nothing else. The vendor's entire business model is predicated on being better at this specific problem than any individual lender can afford to be.
That's not an argument for always buying. It's an argument for being ruthlessly honest about what you're actually buying when you decide to build.
The answer, for most lenders, most of the time
It's not "build" or "buy." It's "buy the commodity, build the edge."
Origination workflows. Servicing and payments. Compliance infrastructure. Document management. Investor reporting. These are solved problems. There are vendors who have spent years and tens of millions of dollars getting them right, and they will spend tens of millions more. Trying to compete with that investment — to build an origination workflow that is meaningfully better than the best commercial alternative — is almost never the right use of a lending company's engineering capacity.
But the proprietary data pipeline that feeds your underwriting model? Build it. The custom integration that connects your loan system to a data source your competitors don't have access to? Build it.
The discipline is knowing the difference. And in 2026, with AI making building cheaper and buying better simultaneously, that discipline matters more than it ever did. Because the cost of getting it wrong — of building the commodity and neglecting the edge, or of building everything and maintaining none of it well — has gotten quietly, significantly higher.
The decision makers are smart. They have the right instincts. They just need to be asked a slightly different question.
Not can we build this? But what, exactly, are we building for?
