A build vs buy framework for AI features — where buying wins, where a thin wrapper is genuinely correct, and the three conditions that justify building AI infrastructure yourself.
CodeKrypt Bot 4 min readThe build vs buy question for AI features gets argued with the wrong evidence. Someone quotes the cost of a vendor licence, someone else quotes the cost of a developer, and the decision goes to whoever made the tidier spreadsheet.
The useful question is narrower: does this capability need to be ours?
Sort every AI capability on your roadmap into one of three buckets before you price anything.
| Bucket | Description | Default |
|---|---|---|
| Commodity | Everyone offers it; nobody chooses you for it | Buy |
| Differentiating | Customers can tell yours is better, and it affects the sale | Build |
| Contextual | Needed internally, invisible to customers | Buy, or automate cheaply |
Transcription, OCR, generic summarisation, standard moderation: commodity. The quality gap between vendors is small and closing, and every hour you spend maintaining one is an hour not spent on the product.
The classifier that encodes your ten years of underwriting decisions, the retrieval layer over your proprietary corpus, the workflow that only makes sense in your customers' operating model: differentiating. That is where owning it compounds.
The failure mode is not choosing wrong once. It is never sorting at all — and then discovering you have built a mediocre in-house transcription service while your actual differentiator runs on a vendor's roadmap.
Vendor pricing for AI features tends to scale with exactly the thing you want to grow: seats, conversations, documents, tokens. That is fine early and uncomfortable later. Three things to check before signing:
The build is the visible part and the small part. What follows it:
That last one decides more of these arguments than any cost model. If you have eight engineers, the question is not whether you can build a retrieval platform — you can — but what does not get built while you do.
Two shifts moved the line in favour of building, and it is worth being precise about them rather than accepting the general enthusiasm.
Open-weight models closed much of the capability gap at a fraction of frontier pricing, which makes self-hosting viable for workloads that are high-volume and narrow. Reporting on 2026 pricing puts open-weight inference roughly an order of magnitude below frontier SaaS at comparable capability tiers — see for example The SaaS Library's build-vs-buy analysis.
AI-assisted development compressed build timelines, so the fixed cost side of the equation shrank. That is real, but it applies mostly to the first version. It does not shrink evaluation, operations or maintenance, which is where the multi-year cost actually sits.
The honest summary: building got cheaper to start and roughly as expensive to own.
"It's just a wrapper" is used as an insult, and it is usually a lazy one. Every AI product is a wrapper around a model, including the ones with large valuations. What determines whether that is a business or a weekend project is what surrounds the call:
A thin wrapper with all five is a good business. A thick custom platform with none of them is an expensive hobby. Build the surrounding layer, buy the model.
The step teams skip is the fourth: they either never revisit the buy decision, or they rebuild everything out of principle. The correct answer is almost always a specific, small piece of the system, identified with data.
If you are pricing the build side of this comparison, what an AI MVP actually costs covers where the money goes, and RAG or fine-tuning covers the architecture choice that follows a decision to build.
When you want the build side scoped honestly — including the parts we would tell you to buy — that is how we approach AI SaaS work.
The 838%-ROI claims in vendor pitches are built on assumptions that don't survive scrutiny. A grounded formula for AI automation ROI, and the costs that get left out.
Where the money goes when you build an AI product MVP — engineering time, model inference, data preparation, evaluation — and which scope decisions move the total most.
Most SaaS products need one or two AI features done well, not nine done shallowly. A filter for telling which pitched features are load-bearing and which are decoration nobody uses.