Last updated: August 14, 2026
By Kris Drouet, Engineering Executive, in partnership with KORE1
Buy the vendor’s AI for the seventy percent every lender needs, document intake, underwriting signals, compliance logging, and build custom only at the one exception queue that is actually yours. Most engineering leaders pick one extreme or the other. The pattern that actually works sits in between, and almost nobody builds it on purpose.
Seven months.
That is how long an engineering team at a lender I was advising spent building a document classifier from scratch, in parallel with a vendor tool the company had already licensed and was already paying for every month. The instruction from the VP of Engineering was reasonable on its face. Do not let us get locked into one vendor’s model. Keep a real option on the shelf, just in case the contract ever goes sideways.
Seven months later the in-house version still misread scanned pay stubs the vendor’s model handled without complaint, the team had shipped nothing else of consequence that quarter, and the actual gap in the workflow, the one thing the vendor genuinely could not do, had never been touched. It sat in a backlog the entire time. Three weeks of work at most, waiting behind a rebuild nobody had asked the right question before starting.
I have written before about build vs buy in AI as a single decision, made once, at the start. That framing is wrong for more situations than it is right for. The real skill in mortgage tech right now is not choosing a side. It is knowing exactly where the vendor’s platform ends and your five percent begins, then building only that five percent, on top of what you already bought.
Twenty-five years watching regulated engineering orgs make this call, and the expensive version is always the same shape. Somebody treats “build on top” as a euphemism for “build again.”
The Two Defaults, and Why Both Are Wrong
Most lenders land on one of two defaults, and neither one is actually a decision. It is an absence of one.
Default one. Buy the platform, accept whatever workflow it ships with, and route every case the vendor’s model handles badly to a human queue forever. This looks cheap on the invoice and expensive on the org chart, because now you are staffing a permanent exception team to compensate for a gap that a few hundred lines of code could have closed.
Default two is the seven-month rebuild. Somebody senior gets nervous about vendor risk, and the response is a shadow system that duplicates most of what the vendor already does well, badly, at your expense, on your timeline. I have written a four-gate checklist for evaluating a vendor before you sign, and this is the failure mode that lives on the other side of that decision. You signed. Then you built the whole thing again anyway, out of a feeling instead of a spec.
Both defaults share a root cause. Nobody drew the line. Not a real line, the kind with an API contract and one engineer’s name next to it. Just a vague sense that “we should keep some control here” that never got translated into an actual scope, a ticket, or a deadline.
What Buy-Then-Build-On-Top Actually Means
Buy-then-build-on-top is an architecture pattern where a team licenses a vendor’s AI platform for its core capability and writes a thin, purpose-built layer against the vendor’s own API to handle the small number of cases the vendor’s stock workflow genuinely gets wrong. The vendor keeps owning the model, the compliance logging, and the audit trail. You own the seam. Nothing else.
The seam is usually small. That is the entire point of the pattern, and it is the part most engineering leaders skip past on the way to a much bigger project.
| Approach | Who owns the model | Who owns the audit trail | Typical time to value |
|---|---|---|---|
| Buy only, no seam | Vendor | Vendor | Weeks, then a permanent manual queue for every gap |
| Build everything in-house | You, entirely | You, entirely | Two to four quarters, if it ships at all |
| Buy, then build on top | Vendor | Shared, at a defined API boundary | Three to six weeks for the seam itself |
Where the Seam Actually Lives in Mortgage Tech
In mortgage tech specifically, the seam almost never lives inside the model. It lives in the routing. ICE’s Encompass platform, the one most of my career has run through in some form, publishes open REST APIs through Encompass Developer Connect specifically so a lender’s own engineering team can read and write loan data without ever touching the vendor’s model code. That is the door. Most teams never walk through it, because it is easier to imagine a whole new system than to ask what one API call actually needs to do.
Back to the lender with the seven-month rebuild. The real gap, once someone finally wrote it down, was three sentences long. Non-QM jumbo files with irregular self-employment income kept getting classified the same way as a standard W-2 file, and the vendor’s document model, trained mostly on the common case, had no strong signal to do otherwise. Nobody should have expected it to. That is not a failure of the vendor’s AI. It is a fact about training data and the ordinary shape of a loan book, and it was never going to be different.
The fix that eventually shipped, after the rebuild was killed, was a routing service. It listened for a webhook off the vendor’s classification event, checked three fields against the loan file, and rerouted anything matching the non-QM pattern into a separate underwriting queue with a human in the loop earlier than the vendor’s default flow would have placed one. Under two hundred lines. It called the vendor’s API. It never touched the vendor’s model. I have written separately about what an Encompass integration actually costs, and this kind of seam sits at the cheap end of that range by a wide margin, because you are extending a system instead of replacing one.
Two questions decide whether something belongs in the seam or belongs to the vendor.
- Does a wrong answer here cost you a bad loan, a bad audit finding, or a customer complaint that lands on your desk specifically, not the vendor’s? If yes, it is probably yours to own.
- Is this already on the vendor’s public roadmap for the next release or two? If yes, wait. Building it yourself just means maintaining something the vendor is about to hand you for free.
Most teams skip both questions and go straight to a build decision made out of anxiety instead of arithmetic. Ask them first. It takes an afternoon, not a quarter.
The Economics Nobody Talks About
Here is why the size of the seam matters more in mortgage tech than almost anywhere else I have worked. The Mortgage Bankers Association put the average cost to originate a loan at independent mortgage banks near $12,200 in 2025, with sales expense alone eating roughly sixty percent of that figure. Engineering has a thin slice of what is left to work with, and a seven-month shadow build stacked against a five-figure origination cost is not a rounding error. It shows up in the next board deck with your name on the line item.
Lenders are not exactly rushing past that math either. Fannie Mae’s Mortgage Lender Sentiment Survey found that only 7% of lenders had fully deployed AI or machine learning tools as of 2023, down from 14% back in 2018, while 22% were running limited or trial deployments. Operational efficiency, not the customer-facing shine everyone assumed would drive adoption, was the reason 73% of lenders gave for touching AI at all, up sharply from 42% in 2018. Nobody is buying AI in this industry to look impressive anymore. They are buying it because the cost-to-originate number will not move any other way, and building the whole thing themselves moves it in the wrong direction.
That tracks with what I keep finding on the buy side generally. Vendors succeed at roughly twice the rate internal builds do, and the mortgage-specific numbers above explain a good part of why. A vendor’s document model, underwriting signals, and compliance logging get amortized across every lender who buys the platform. Your seam gets amortized across nobody but you. Which is exactly why it should stay small, on purpose, every time.
KORE1 fills engineering and AI roles in about 17 days on average, with a 92 percent twelve-month retention rate on direct-hire placements, and the pattern across those searches tracks the same line I keep drawing here. The lenders who staff correctly for buy-then-build-on-top hire one senior integration engineer who can read a vendor’s API docs cold and ship the seam in a month. The lenders who staff for the seven-month rebuild hire four people, and then call a recruiter eight months later asking why nothing shipped.
Questions Engineering Leaders Ask Me About This
Isn’t this just build vs buy with extra steps?
No, and the difference matters. Build vs buy asks you to choose a side once, up front. Buy-then-build-on-top assumes you already bought, and asks a narrower, harder question. Exactly which three sentences of your workflow does the vendor not cover? Most teams never write those three sentences down. They jump straight to a build decision instead.
How do you actually find the seam before you commit engineering time to it?
Pull ninety days of exception-queue data from whatever the vendor’s tool already routes to a human. The seam is hiding in whatever pattern repeats. If one loan type or one document format shows up in that queue at three or four times the rate of everything else, that is your seam. Everything else stays with the vendor, no exceptions.
What if the vendor genuinely does not expose an API for the thing we need?
Then buy-then-build-on-top is not available to you yet, and you are choosing between the manual queue and the full rebuild, a much worse set of options. Ask the vendor directly and get the answer in writing before you assume either way. Most platforms I have worked against, Encompass included, expose far more than most engineering teams bother to check.
Who ends up owning the thin layer once it is built?
One engineer, by name. Not a team. A seam this small does not need a squad, and assigning one is usually how a three-week fix quietly grows back into the seven-month rebuild it was supposed to replace in the first place.
Does this apply outside of document intake and underwriting exceptions?
It does. I have run the same pattern on pricing engines and on servicing workflows. The mortgage-specific detail changes every time. The two questions that decide what belongs in the seam do not.
Already seven months into a shadow build somewhere else. Worth switching now?
Almost always, and it gets more expensive every month you wait on it. Kill the parts of the rebuild that duplicate the vendor. Keep whatever piece was actually solving your specific gap, wrap it in an API call to the vendor for everything else, and ship what is left. You will lose less than it currently feels like you are losing.
Draw the Line Before You Write Code
The lender from the start of this piece eventually shipped the routing service in three weeks, not seven months. Same engineer who wrote the abandoned classifier wrote it, once someone finally handed her the actual question instead of a mandate to rebuild something that already worked fine.
Show me the data before you greenlight a build next to something you already bought. Most of the time the data says the gap is smaller than the anxiety about it, and cheaper to close than the meeting where everyone agreed to rebuild it did.
If you are staring at a vendor AI platform right now wondering how much of it to trust and how much to rebuild around, message me on LinkedIn and walk me through it. I read every one.
And if the honest answer is that you have the seam scoped but nobody on the team who can own it, KORE1’s mortgage tech engineering staffing team has filled that exact role before, usually as a contract hire brought on for one integration instead of a whole rebuild. Start with a conversation before you start a seven-month project you will end up unwinding anyway.
