The CTO's AI buy-vs-build framework

Every CTO we work with has the same conversation at least quarterly. The board wants "AI." Product wants "AI." Engineering wants to know what that actually means and who's paying for it. The buy-vs-build decision usually gets made in the wrong room — by people who don't see the operating costs — and then engineering inherits it. This framework is what we wish more CTOs had at hand when the conversation starts.

Two questions, four answers

Strip the whole conversation down and almost every AI feature you're considering can be plotted on a 2×2 grid built from two questions:

• Is this feature core to your differentiation? — would competitors copying it harm your business?
• Is the data you'd train or ground it on uniquely yours? — or is it general-purpose information any model already has?

The four quadrants give you four very different answers.

Quadrant 1: Not core, not proprietary — buy it

If the feature doesn't differentiate you and the underlying capability is general, buy. Email summarisation. Translation. Speech-to-text for meeting recordings. Content moderation for a community feature. These are commodity capabilities that vendors will provide cheaper, better, and faster-improving than you can build.

The trap here is "we want to learn AI by building it." If learning is the goal, fine — but pick a feature that also matters. Don't burn six months building a worse version of something you could have bought for $200/month.

Quadrant 2: Not core, but proprietary data — buy + ground

An internal helpdesk that answers questions about your HR policies. A customer-support assistant that knows your product catalogue. An onboarding bot that walks new hires through company-specific tooling.

The capability (Q&A over documents) is general. The value comes from your private data. Buy a platform like a hosted RAG-as-a-service or use a vendor that gives you a managed retrieval pipeline — and feed your documents in.

You don't need to build this from scratch. The differentiation comes from your data, not your retrieval algorithm. The vendor's retrieval is probably better than what you'd ship in six months anyway.

Quadrant 3: Core, but no proprietary data — build with frontier models

This is the trickiest quadrant. The feature matters to your business — it's part of your product, customers see it, competitors care — but the underlying intelligence is general.

The right move: build on top of frontier models (Claude, GPT, equivalent) with a strong prompt-engineering practice and tight integration into your product. Don't fine-tune. Don't host your own. The frontier providers will improve their models faster than you can improve a custom one, and you'll capture that improvement for free.

Examples from our portfolio: Adsage's ad-matching engine started here. The differentiation is in how it integrates with the customer's ad-tech stack, the prompt engineering, the eval harness. The model itself is the same one anyone else can rent.

Quadrant 4: Core and proprietary data — this is where you build

You differentiate on something only you can do, and the data that powers it is yours alone. This is where serious investment pays off. Real engineering time, RAG infrastructure, possibly fine-tuning, definitely your own eval harness.

Our BluCognition FraudLens sits here — the fraud-detection capability matters to the customer's business, and the training data (10M+ documents) is uniquely the client's. So is Nuron for pharma — the data is the moat, and the AI on top of it is custom.

This is also the quadrant where most companies think they live but actually don't. Be honest. Is your customer-support data really uniquely valuable? Or is it just "your customer-support data" — which every competitor also has, about their own customers?

The two questions everyone forgets

Two questions get skipped that radically change the answer:

1. How long until the frontier closes this gap?

Every six months, frontier models swallow another category of "things you used to need a custom model for." Sentiment analysis was a build in 2020 and a buy in 2024. Document classification was a build in 2022 and a buy by 2025. Specialised medical NER is probably a build today and a buy by 2028.

If the answer is "12-18 months," build with frontier models on top — you'll re-platform onto the new commodity capability when it arrives. If the answer is "5+ years," a custom build can pay back.

2. What's the operating cost at year three?

Build conversations focus on build cost. Operating cost is where projects die. A custom fine-tuned model needs: ongoing eval, drift monitoring, retraining when data shifts, infrastructure to host inference, security review, vendor management for the training compute. The team running this isn't your prototyping team — it's a permanent capability.

Most CFOs are happy to fund a $400k build. They're less happy to fund $250k/year in ongoing AI ops they didn't budget for. Surface this conversation early.

What we actually recommend, in three patterns

Across all the companies we work with, three patterns describe 90% of well-executed AI strategies:

1. "Buy everywhere, build the differentiator" — most features are SaaS or API; one or two genuinely-differentiating features get senior engineering attention. Works for product companies with one or two clear AI bets.
2. "Build the platform, buy the features" — invest heavily in a shared AI platform (eval, observability, governance, retrieval) and let product teams pick which models and vendors to use on top of it. Works for larger organisations shipping AI across many surfaces.
3. "Partner for the regulated build" — the AI is core, the data is proprietary, but the regulatory and engineering complexity is outside the team's normal range. Bring in a specialised partner for the build, retain operational ownership. This is most of what OlloSoft does.

The three sentences that resolve most arguments

When the buy-vs-build conversation gets stuck, three sentences usually clear it up:

• "If we bought this, would we be embarrassed by the result in six months?" If yes, build. If no, buy.
• "If we built this, what would frontier models look like by the time we ship?" If they'd match us, don't build the model — build the integration around them.
• "If this feature went to zero tomorrow, would customers leave?" If yes, build. If no, buy.

AI strategy isn't really about AI. It's about figuring out where you actually have an edge and protecting that, while spending as little energy as possible on everything that doesn't move the needle. The buy-vs-build framework just makes the second part easier to see.