The AI Architect's Build vs Buy Decision Framework

The build versus buy question is the most consequential decision I make as an architect, and AI has made it harder, not easier. A few years ago the trade-off was reasonably stable: build for differentiation, buy for commodity, hybrid for the awkward middle. Today the commodity is moving so fast that yesterday’s differentiator is tomorrow’s API call, and the AI vendor landscape changes from quarter to quarter. I have watched teams spend six months building capabilities that a vendor released two months later, and other teams buy products that became obsolete the moment the underlying model improved.

I have settled on a structured framework I now apply to every significant AI capability decision. It is not a script. It is a set of questions and trade-offs that force the team to be honest about what is differentiated, what is commodity, and what the total cost looks like over three years rather than the first quarter.

In this article I will share the ai build vs buy framework I use, the five questions I screen every decision against, the trade-offs that swing decisions in each direction, the hybrid pattern that I increasingly default to, real cases where build was the right answer, real cases where buy was the right answer, and the TCO mistakes that I see organisations make repeatedly.

Three things make AI build versus buy different from classical software:

• The capability frontier is moving. Vendors ship new models and features every quarter. Whatever you build today may be commoditised in months.
• Data is the moat, not code. The competitive advantage in many AI use cases is the proprietary data, the labelling pipeline, and the evaluation set, not the model architecture.
• Switching costs differ by layer. Switching foundation models is now reasonably cheap if you have built behind a well-designed abstraction. Switching a vertical SaaS product is expensive because it is wired into business processes.

Architects who treat AI build versus buy as a pure cost decision miss the strategic question. The right question is what is differentiated, what is commodity, and where the boundary will move next year.

I have seen organisations build vector databases from scratch because they wanted “control” and then realise three months later that they had built a worse version of what three vendors offer for a tenth of the cost. I have also seen organisations buy entire industry-specific AI products that locked them into a vendor’s roadmap and prevented them from acting on their actual differentiation.

Before any deep analysis, I run every candidate decision through five questions. If the answers are clear, I rarely need the deeper framework.

1. Is this capability core to our differentiation, or is it table stakes? Core gets built or heavily customised. Table stakes gets bought.
2. Do we have proprietary data that gives us an unfair advantage? If yes, lean towards build or fine-tune. If no, lean towards buy.
3. Do we have the in-house expertise to operate this for three years? Without sustained expertise, build becomes shelfware.
4. What is the time-to-value pressure? Six weeks favours buy. Six months allows build to be considered.
5. What happens if the vendor doubles their price or changes terms? If the answer is catastrophic, do not buy without contractual protection.

If a candidate fails questions one or two, the answer is buy. If it fails questions three or four, the answer is buy. If it fails question five, the answer is either build or hybrid with a robust exit strategy. Most decisions resolve at this screen.

Building is the right call when:

• The capability is genuinely differentiating, not a checkbox.
• You have proprietary data that you cannot share with a vendor, or that would give a vendor’s other customers a window into your strategy.
• You need full control over latency, cost, deployment topology or audit.
• The use case is so specialised that no vendor will prioritise your roadmap.
• The TCO of building, including operational costs over three years, is materially lower than buying.

Examples I have seen succeed:

• A bank built its own document understanding model because the corpus was bank-specific and the labelling effort was already sunk into existing processes.
• A logistics company built a routing optimiser because the optimisation surface mattered enormously to margin and no vendor solution captured the full constraint set.
• A research organisation built its own RAG infrastructure because the corpus was too sensitive to leave the on-prem environment.

In each case the team understood that they were taking on operating cost forever, and they were comfortable that the value justified it.

Buying is the right call when:

• The capability is commodity, increasingly so, and not part of differentiation.
• Time to value is critical. A six-week deployment beats a six-month build.
• You lack in-house expertise and cannot reasonably build it.
• The vendor has strong references in your sector and a clear roadmap aligned with your needs.
• The TCO over three years is competitive with build, especially after accounting for opportunity cost.

Examples:

• A retailer bought a vendor copilot for store associates because the use case was well-understood, the vendor had retail-specific features, and the build alternative would have cost twice as much and arrived nine months later.
• A professional services firm bought a meeting summarisation product because none of their differentiation lay in summarising meetings.
• A healthcare provider bought a coding assistant for developers because the use case was identical to what every other developer faces.

The signal that buy is right is usually that the vendor’s product solves 80 percent of your need on day one. If you are negotiating for 80 percent of the product to be customised before it is useful, the actual cost is build, not buy.

Increasingly, the right answer is hybrid: buy the foundation and customise the parts that matter. This pattern has become my default for AI because it gets the time-to-value of buying with the differentiation of building.

A typical hybrid stack:

• Foundation models from vendors, behind a routing abstraction so you can switch.
• Vendor RAG or agent platform, customised with your data, your prompts and your evaluation sets.
• Proprietary components for the differentiated bits, which might be a fine-tuned model, a domain-specific retrieval pipeline, or a critical evaluation framework.

Done well, this pattern gets you 80 percent vendor leverage and 20 percent owned differentiation. Done poorly, it gets you a tangle of vendor lock-in and homegrown debt. The discipline is to be ruthless about what is genuinely differentiating and what is not.

The hybrid pattern is the right answer about 60 percent of the time in my experience. The mistake is to pretend it is the right answer 100 percent of the time. Some capabilities should be fully built, others fully bought.

Vendor proposals understate TCO. Build estimates understate TCO too. My checklist for honest TCO calculation includes:

For build: - Engineering salaries, fully loaded, for the full team over three years. - Infrastructure, including non-production environments, multiplied by 1.5 for redundancy. - Tooling, licences and observability stack. - Security, compliance and audit overhead. - Opportunity cost of the team not doing other work. - Maintenance, on-call and incident response.

For buy: - Licence fees over three years, including escalation clauses. - Implementation services and customisation. - Integration engineering time on your side. - Training and change management. - Switching cost if you have to leave the vendor.

I usually find that build is more expensive than the initial estimate by a factor of two to three, and buy is more expensive than the headline by a factor of 1.3 to 1.5 after integration and switching reserves.

Buy decisions create vendor dependency. Architects need to think about this explicitly.

Risks I assess:

• Concentration. What share of your AI spend goes to a single vendor? Above 30 percent is uncomfortable.
• Capability risk. Will the vendor still be ahead of the open-source frontier in three years?
• Commercial risk. Could the vendor be acquired, change pricing, or change terms in a way that breaks your business model?
• Data risk. Does the vendor’s data handling stay aligned with your regulatory obligations?
• Strategic risk. Could the vendor become a competitor in your industry?

Mitigation patterns include multi-vendor strategies, abstraction layers that allow swapping, contractual protections, and structured exit plans. The goal is not to avoid vendor dependency, which is usually unavoidable. The goal is to make it conscious and survivable.

When the five-question screen does not resolve, I lay out a structured decision matrix. The factors I weight:

Each option scores against each factor on a one-to-five scale. The weighted sum is one input, but it is not the answer. The answer comes from the conversation the matrix forces, not the number it produces.

A trading firm I worked with wanted a copilot for their trading desk. Off-the-shelf copilots existed, but none understood their proprietary instruments, their internal compliance rules, or their workflow. They also operated under model risk management rules that required full transparency into model behaviour.

We built. The team consisted of three engineers, a quant and a domain expert. The first version took four months. The model was a fine-tuned open-source LLM running on dedicated infrastructure with full audit logs. Integration with their order management system was bespoke.

Three years on, the system is still running, has been re-platformed once, and is treated as a strategic asset. Build was the right call because the differentiation was real, the regulatory constraints made buy untenable, and the firm had the expertise to operate it.

A mid-sized software company wanted to give their engineers AI coding assistance. The vendor market was crowded. The use case was identical to what every other engineering team faces. The CTO wanted productivity gains within a quarter.

We bought. The selection process took six weeks, the rollout three months, and the productivity uplift was measurable within a release cycle. The vendor handled model updates, IDE integrations, security reviews, and roadmap. The total cost was a fraction of what building would have been, and the result was better than what a small internal team could have produced.

Buy was right because none of the company’s differentiation lay in how their engineers wrote code. They wanted productivity, not control.

A pharmaceutical company wanted internal RAG over their regulatory and research documents. The corpus was sensitive. The use case was generic. The team was small.

We went hybrid. The foundation model came from a hosted vendor with a Business Associate Agreement. The RAG platform came from a vendor with strong enterprise features. The retrieval pipeline, evaluation framework and access controls were built in-house because the data sensitivity and the audit requirements were specific to the regulated environment.

The hybrid pattern got the team to production in three months. It also gave them the architectural posture to swap any single component if the vendor landscape shifted, which it did twice in the next two years.

The build mistakes I see most:

• Underestimating ongoing operational cost.
• Building components that vendors offer in commodity form.
• Building when the team lacks the depth to maintain it.
• Ignoring the opportunity cost of the engineering team’s time.

The buy mistakes I see most:

• Confusing vendor capability with vendor commitment.
• Signing without clear exit terms.
• Buying a platform when you needed a feature.
• Customising so heavily that you have effectively built, with the vendor’s lock-in as a bonus.

A bad build is a sunk cost you have to maintain. A bad buy is a contract you have to honour. Both are recoverable, but only at meaningful cost. The discipline is to avoid both.

Decisions are not permanent. Sometimes the right thing is to abandon a build and buy, or vice versa.

Signals to reverse from build to buy: - The vendor market has matured past your build. - The opportunity cost of maintenance is too high. - The system has not kept pace with foundation model improvements.

Signals to reverse from buy to build: - The vendor’s roadmap has diverged from your needs. - The TCO has grown faster than your usage. - The vendor’s data handling no longer aligns with your obligations.

Reversal is uncomfortable because someone made the original decision and it implies they were wrong. The discipline is to separate the original decision from the current situation and ask what the right call is today.

Build versus buy is not a one-off. It is a portfolio discipline. The governance I recommend:

• A standing AI architecture review that holds the inventory of build versus buy choices.
• Quarterly portfolio review against the moving frontier.
• Decision logs that capture not just what was decided but why, so that reversals are well-informed.
• A clear delegated authority. Decisions below a threshold sit with the architect; above the threshold they need executive sign-off.

Without governance, decisions accumulate as one-offs and the portfolio drifts. With governance, the organisation can act on a strategy rather than reacting to vendor pitches.