Build-versus-buy is one of the oldest questions in technology, but AI made it genuinely harder. Foundation-model APIs collapsed the cost of building a basic capability to a few lines of code, which makes building feel cheap. Vendors wrapped those same models in polished products with support and SLAs, which makes buying feel safe. And in the gap between them sits the trap that caught a lot of teams in 2024 and 2025: the thin wrapper — a feature that is just a prompt over someone else's model, easy to build, easy for anyone else to build, and impossible to defend. This framework is for the technology leader deciding where to spend engineering quarters. It is not a formula that outputs an answer; it is a set of questions that, asked honestly, keep you from committing real resources to the wrong side of the line.
Start With Core vs Context
The oldest and still most useful lens is Geoffrey Moore's distinction between core and context. Core is what differentiates you in the eyes of your customer — the thing they pay you for and cannot get elsewhere. Context is everything else that has to work but does not differentiate. The principle: build your core, buy your context. The AI-specific trap is that the foundation model itself is almost never your core. The model is context — a commodity input available to every competitor on identical terms. Your core, if you have one, is what you do with it: your data, your workflow, your domain expertise encoded into the system. Building a wrapper around a model you do not control, to do something generic, is building context badly while buying nothing.
- Core = what differentiates you to the customer; build it. Context = necessary but undifferentiated; buy it
- The foundation model is almost always context — a commodity input every competitor can buy too
- Your potential core is the data, workflow, and domain expertise layered on top of the model
- Building a generic capability around a model you do not own is the worst of both worlds
- Ask of any AI feature: is this differentiating, or is it table stakes we should acquire cheaply?
The Thin-Wrapper Trap
The defining build mistake of the early generative-AI era was the thin wrapper: a product or feature that is essentially a prompt and a text box over a frontier model. It feels like building — there is code, there is a deploy — but it creates no defensibility, because anything you can build with a prompt, a competitor can build with the same prompt next week, and the model vendor might ship it natively the week after. The test is simple and brutal: if your AI feature could be replicated by a competent engineer in a weekend using the same public API, you have not built a moat, you have built a liability with ongoing token costs. That does not always mean do not build it — sometimes a thin wrapper is a fine convenience feature — but never mistake it for differentiation.
- A thin wrapper is a prompt and a UI over someone else's model — code without defensibility
- The weekend test: if a competent engineer could rebuild it in a weekend on the same API, it is not a moat
- Model vendors routinely absorb popular wrapper features into the base product, erasing your work
- Thin wrappers can be legitimate convenience features — just never budget for them as differentiation
- Defensibility in AI comes from data, distribution, and workflow integration, not from prompt cleverness
Where Defensibility Actually Comes From
If the model is a commodity, the obvious question is where durable advantage lives, and the answer reframes the whole build decision. It comes from assets that compound and that a competitor cannot simply buy: proprietary data that improves your system in ways no public model has access to; deep integration into a customer's workflow that raises switching costs; domain expertise encoded so specifically that a general model cannot match it; and distribution — being where the customer already is. The build-versus-buy question then sharpens. Build the parts that create or exploit these moats. Buy or rent the commodity capability underneath. The teams that won with AI did not build better models; they built defensible systems on top of commodity ones.
- Proprietary data — the one input competitors and public models genuinely cannot replicate
- Workflow integration — embedding so deeply into how the customer works that leaving is costly
- Encoded domain expertise — specificity a general-purpose model cannot match out of the box
- Distribution — being where the customer already is beats a marginally better feature they never find
- Build to create and exploit these moats; rent the commodity model capability beneath them
Total Cost Is More Than the API Bill
The build-side cost of an AI feature is systematically underestimated because the API call is the cheapest part. The real cost is everything around it: the evaluation suite to know it works, the observability to know when it breaks, the guardrails for safety and prompt injection, the ongoing prompt and model maintenance as providers deprecate and re-price, and the on-call burden of a non-deterministic system in production. On the buy side, the under-counted costs are different but real: per-seat or per-call pricing that scales with success, data-residency and compliance constraints, and the integration tax of bending your workflow to the vendor's model. Compare the honest totals, not the sticker prices — a build that looks cheap at the API line is often expensive at the system line, and a buy that looks expensive per seat is often cheap against the engineering it replaces.
- Build's hidden costs: evals, observability, guardrails, prompt/model maintenance, and on-call for non-determinism
- Foundation-model pricing changes — budget for re-pricing and deprecation, not today's rate forever
- Buy's hidden costs: usage-based pricing that scales with your success, plus integration and compliance friction
- Data residency and compliance can rule a vendor in or out regardless of price
- Compare honest total cost of ownership, not API sticker price versus per-seat sticker price
Switching Costs and the Reversibility Test
A decision you can cheaply reverse deserves far less deliberation than one you cannot, and AI decisions vary enormously on this axis. Buying creates vendor lock-in proportional to how deeply the vendor's model is woven into your product and how much of your data lives in their system. Building creates a different lock-in — to the maintenance burden and to the specific model and prompts you built around. The practical hedge is an abstraction layer: route model calls through your own interface so that swapping a provider, or moving from a bought feature to a built one as it becomes core, is a contained change rather than a rewrite. Favor reversible decisions when the answer is genuinely unclear, and reserve the irreversible commitments for the cases where the strategic call is obvious.
- Buying locks you to a vendor in proportion to integration depth and data gravity
- Building locks you to maintenance and to the specific model and prompts you chose
- Abstract model access behind your own interface so provider swaps are contained, not rewrites
- Prefer reversible decisions when the call is unclear; save irreversible bets for the obvious cases
- Re-evaluate periodically — a feature that was context last year can become core as your product matures
A Practical Default Sequence
Frameworks are only useful if they produce action, so here is the default sequence we recommend to most teams weighing an AI feature. It biases toward learning cheaply before committing expensively, because the cost of being wrong about build-versus-buy is measured in engineering quarters. Start by buying or renting to validate that the capability matters to customers at all; nothing is worse than building a defensible moat around a feature nobody wanted. Then build only where you have established both that it matters and that you have a genuine moat to exploit. This is not timidity — it is sequencing irreversible spend behind the cheap evidence that justifies it.
- Step 1 — Validate demand with a bought or rented capability before building anything custom
- Step 2 — Identify whether you have a real moat (data, workflow, expertise, distribution) to exploit
- Step 3 — Build only where the feature both matters to customers and lets you exploit a moat
- Step 4 — Buy the commodity capability underneath your build; do not reinvent the model layer
- Step 5 — Keep an abstraction layer so today's buy can become tomorrow's build without a rewrite
- Throughout — revisit the decision as features migrate between context and core over time
Conclusion
AI did not repeal the logic of build-versus-buy; it sharpened the stakes and added a new trap. The foundation model is commodity context, not your core, and building a thin wrapper around it produces code without defensibility. Real advantage comes from the assets a competitor cannot buy — proprietary data, workflow integration, encoded expertise, distribution — and the build decision should follow that line: build where you exploit a moat, buy the commodity capability beneath it, and keep an abstraction layer so the decision stays reversible as your product evolves. The leaders who navigate this well are not the ones with the strongest opinion about building or buying in the abstract; they are the ones who ask, honestly, whether a given feature is core or context, whether it could be rebuilt in a weekend, and whether the total cost they are comparing is the real one. Asked rigorously, those questions spend your engineering quarters where they compound. At Sensussoft, that is the conversation we have with clients before a line of AI code is written, because it is far cheaper to have it then than after.
About Vinod Kalathiya
Vinod Kalathiya is a technology expert at Sensussoft with extensive experience in business strategy. They specialize in helping organizations leverage cutting-edge technologies to solve complex business challenges.
