MIT’s 2025 study of generative AI deployments found that tools bought from specialized vendors succeeded about 67% of the time. Internal builds succeeded only one-third as often. The study is not about lending. It still points to what lenders can miss when they compare build and buy: delivery risk, not just price.
Quick Answer
Building gives a lender control but concentrates cost, delivery and maintenance risk in one team. Buying shifts delivery risk to a vendor but adds vendor dependence, which regulators expect you to manage. Most lenders end up with a mix: buy the core platform, then build only what sets their credit process apart.
Key Takeaways
- Compare five-year total cost, not internal build cost against first-year licence fees.
- Measure time to the first live loan and the second product, not time to code completion.
- Include maintenance, security, regulatory change and key-person risk in the build case.
- For a bought platform, test configurability, open interfaces, audit rights and exit provisions.
What Does the Build vs Buy Decision Cover
The decision is not about one purchase. It covers three questions over the life of the system:
- Cost: what it takes to build or license, run, change, and eventually replace the platform.
- Delivery time: how long until the first loan runs through it.
- Operational risk: what happens when staff leave, a vendor fails, or a regulator asks for evidence.
Cost usually gets the most attention. Delivery and operational risk often decide the outcome.
How Do Costs Compare
Compare options over five years, not at launch. A build looks cheaper when only license fees are counted against it.
| Cost item | Build | Buy |
|---|---|---|
| Initial cost | Design, engineering, testing, infrastructure | Implementation, configuration, data migration |
| Recurring cost | Engineers, hosting, security, compliance updates | License or subscription, support |
| Change cost | Engineering time for each new product or rule | Configuration, or vendor change requests |
| Regulatory change | Your team tracks and codes each rule | Vendor ships updates, you test them |
| Exit cost | Rewrite or migrate off your own code | Data export and contract termination |
Large IT projects in general run over budget. An Oxford and McKinsey study of more than 5,400 projects found an average overrun of 45%. It covered projects with initial price tags above $15 million and does not split build from buy. Use it as a reference for contingency, and treat a build budget as a range, not a point.
How Does Delivery Time Compare
The same study found large projects ran 7% over schedule on average. That is far smaller than the cost overrun. The larger problem is what the project delivers: the same projects delivered 56% less value than predicted.
The Project Management Institute (PMI) adds recent evidence. Its 2026 Pulse of the Profession reports that 31% of complex projects fail to achieve their full intended benefits. Projects that navigate complexity effectively were five times more likely to succeed.
For lenders, time to first loan matters more than time to code complete. Ask both options the same questions:
- How long until one product runs live end to end?
- Which dependencies sit outside the team, such as bureaus and payment partners?
- How many months until a second product launches?
A bought platform can start sooner, but only if configuration fits your products. A build can fit exactly and still arrive late.
The MIT NANDA report cited above covered AI deployments across industries, not lending platforms. Lending-specific studies of build outcomes are scarce. Treat it as directional evidence that internal builds carry execution risk. It does not prove that buying always wins.
What Operational Risks Come With Each Option
Each choice swaps one set of risks for another.
| Risk | Build | Buy |
| Key-person dependence | High, since few engineers know the code | Lower, spread across the vendor team |
| Vendor failure | None | Needs a continuity and exit plan |
| Change speed | Limited by internal capacity | Limited by vendor roadmap |
| Security and audit evidence | You produce all of it | Shared, with vendor evidence to review |
| Regulatory updates | Your team owns every change | Vendor ships, you validate |
| Lock-in | Low from vendors, high to your own code | Depends on data export and contract terms |
Regulators treat vendor dependence as a managed risk, not a reason to avoid buying. Two examples show the pattern.
- United States: The Federal Reserve, FDIC and Office of the Comptroller of the Currency issued joint guidance in June 2023. It says using third parties does not diminish a bank’s responsibilities. It describes five lifecycle stages: planning, due diligence, contract negotiation, ongoing monitoring, and termination.
- European Union: The Digital Operational Resilience Act (DORA) applies from January 17, 2025. Financial entities must keep a register of contracts with information and communication technology (ICT) providers. They also need exit strategies and termination provisions.
If you buy, build these tasks into the plan from day one.
When Does Building Make Sense
Building can be the right call. It tends to fit when:
- Your credit process is the product, and no vendor can configure it without losing what makes it work.
- You have a stable engineering team that can run the system for years.
- Your volumes or products are narrow enough that a small system covers them.
- You can fund regulatory change tracking, security testing, and audit evidence as permanent costs.
Buying tends to fit when you need several products live quickly, or when regulatory change is frequent. It also fits when you lack a standing engineering team.
Is a Hybrid Approach Realistic
Many lenders do both. They buy the platform for origination, servicing, and reporting. They build the pieces that express their own credit strategy, such as scoring logic or partner integrations.
For this to work, the bought platform must expose open interfaces and configurable rules. Otherwise the custom pieces become fragile workarounds. Test this in the evaluation, not after signing.
Build vs Buy Evaluation Checklist
- Are both options priced over five years, including change and exit costs?
- Does the build budget carry a contingency based on overrun data?
- Can you name the team that will run the build in year three?
- What is the time to first loan, and to the second product, under each option?
- Does the vendor contract cover audit rights, incident notice, and data return?
- Is there an exit plan that meets your regulator’s expectations?
- Which parts of your credit process need custom logic?
- Do the platform’s interfaces support that logic without workarounds?
Bottom Line
Build vs buy is a question about where you want risk to sit. Building concentrates cost and delivery risk. Buying adds vendor and regulatory oversight work. Price both over five years, plan the vendor controls that regulators expect, and build only where your credit process needs it.
