Build vs buy for AI features: a framework for non-hype decisions
August 18, 2026 · Muhammad Hammad · Co-founder & Engineer, Vision Nexera · 1 min read
Buy the capability, build the workflow. Raw model intelligence is a commodity you should rent from providers; the way that intelligence meets your data, your process, and your users is where differentiation lives, and it is the part worth building. Most 'build vs buy' confusion dissolves once those two layers are separated.
## What to buy without guilt
Foundation models, transcription, embeddings, OCR: capabilities where providers spend billions and improve monthly. Building these yourself is almost always strategy cosplay. The same logic extends to true commodity workflows: if an off-the-shelf tool does ninety-five percent of a generic job (meeting notes, generic support deflection) buy it and move on.
## What to build
- Anything trained on the shape of your data: extraction, matching, and scoring tuned to your domain - Workflows that encode your process: the approval gates, exceptions, and judgment calls that make it yours - Features where the AI output is your product, and 'as good as everyone's chatbot' is a losing bar - The boundary layer itself: the contracts, evals, and routing between your product and the model world
## The pattern that keeps you honest either way
Whether you buy or build, put a boundary layer you own between your product and the AI: typed contracts in, structured outputs back, evaluation and logging in the middle, provider routing behind it. Buying becomes low-risk because the vendor sits behind an interface you can swap; building becomes tractable because the scope is a component, not a platform. The teams in trouble are the ones whose product code calls a vendor SDK on four hundred lines directly.
## The total-cost honesty section
Building costs more than the build: evals, monitoring, and model migrations are the ongoing bill, and it should be budgeted from day one. Buying costs more than the subscription: per-seat pricing scales badly, roadmaps move without consulting you, and your data usually improves someone else's product. Neither cost is a reason to panic; both are reasons to decide with the full invoice on the table.
A fair one-hour test for any feature: if the answer to 'does this touch our proprietary data or encode our process?' is no twice, buy it. If it is yes twice, build it behind the boundary. If it is one of each, pilot cheap and let the evaluation numbers, not the demo, make the call.