The roadmap had six AI features. Engineering wanted to build custom RAG pipelines, fine-tuned classifiers, and an in-house eval framework. Sales wanted shipped demos last quarter. Finance ran the numbers: inference at projected usage erased forty points of gross margin on the tier where AI was the headline. Build vs buy for AI features is not a technology religion. It is a margin and moat calculation — build what differentiates and compounds; buy or bundle what users expect as table stakes; never build commodity intelligence on custom infrastructure unless unit economics prove sustainable.
Every AI feature carries ongoing cost — tokens, GPUs, labeling, eval, incident response when models misbehave. Build multiplies that cost with engineering headcount. Buy concentrates it in vendor bills. Neither is free. The question is where competitive advantage lives and whether price times usage leaves room for profit.
The decision frame: moat, margin, and control
| Factor | Build lean | Buy lean |
|---|---|---|
| Differentiation | Core to product story | Commodity ("AI summary") |
| Gross margin at scale | Margin absorbs inference + eng | Vendor price × usage fits COGS model |
| Data advantage | Proprietary flywheel justifies custom | Generic capability, no unique data |
| Time to market | Can wait quarters | Need shipped this quarter |
| Compliance | Data cannot leave boundary | Vendor meets certifications |
| Customization depth | Workflow unique to domain | Standard LLM task |
AI gross margin reset applies before build decisions — if inference COGS breaks the pricing model, building more AI surface area deepens the hole. Fix pricing and unit economics before debating build vs buy.
Building a wrapper on OpenAI is not a moat. It is a hosting bill with a logo.
What "buy" means in AI (spectrum)
Buy is not only "use vendor SaaS." Spectrum:
1. Raw model API. Fastest; least differentiated. Appropriate for internal tools, prototypes, non-core features.
2. Managed AI services. Document parsing, moderation, speech — vendor owns model lifecycle. Appropriate when capability is standard and SLAs matter.
3. Platform bundles. Cloud provider AI suites — trade portability for integrated billing and compliance.
4. Acquisition / OEM. Embed vendor white-label — speed with brand risk.
5. Partner integration. Marketplace listing — revenue share, limited control.
Build sits at the end: custom models, proprietary pipelines, unique agent orchestration tied to product data loops competitors cannot replicate.
What deserves build investment
Build when all of the following hold:
- Feature is on the critical path of why customers choose you over alternatives.
- Proprietary data or feedback improves the feature in ways vendors cannot access.
- Unit economics work at 3× projected usage — not demo usage.
- Team can own eval, safety, and regression — not ship v1 and walk away.
- Buy options would require unacceptable customization or lock-in worse than internal cost.
Examples that often justify build: domain-specific agent that executes core product workflows, recommendation driven by unique behavioral dataset, compliance-sensitive pipeline where vendor data handling fails audit.
Examples that rarely justify build: generic summarization, standard chatbot on public docs, image generation for marketing assets, spelling correction.
Hidden build costs teams underestimate
| Cost line | Build impact |
|---|---|
| Inference at scale | Often 10–100× prototype cost |
| Eval and regression | Ongoing labeling, human review |
| Model deprecation | Base model upgrades break prompts/tuning |
| Incident response | Wrong answers are product incidents |
| Security review | Prompt injection, data leakage paths |
| Opportunity cost | Same engineers not shipping core product |
RAG retrieval quality before custom training — build decisions often assume custom stack is necessary when retrieval and prompts are not exhausted.
Fine-tuning as last resort — build rarely starts with training; when build includes fine-tuning, budget retraining as recurring line item.
Hybrid pattern: buy infrastructure, build workflow
Most SaaS lands here:
- Buy model inference API.
- Build product workflow, UI, permissions, audit, integrations.
- Build eval on proprietary tasks.
- Buy monitoring for model layer where sufficient.
Differentiation is workflow + data + trust, not hosting the transformer. Customers pay for outcomes inside your product, not for you running weights slightly differently than a vendor.
How should product and engineering decide build vs buy?
These questions force explicit tradeoffs before roadmap commitment.
When does "build" mean fine-tune vs full stack?
Fine-tuning is build-light; full pipeline ownership is build-heavy. Match investment to moat strength — fine-tune for format stability on proprietary data; do not fine-tune commodity summarization.
Can pricing absorb bought AI at scale?
Model vendor COGS into pricing before build vs buy meeting. If buy breaks margin, build usually breaks worse unless build reduces per-unit inference cost materially.
What is the exit plan if vendor terms change?
For buy: data portability, alternative model routing, contract terms. For build: base model dependency, training data ownership, rollback to API model if internal stack fails.
A common argument runs the other way
The opposing view holds that buy creates vendor dependency and feature sameness — that every serious product company must own AI stack to win.
Dependency is real — mitigate with abstraction layers and multi-model routing. Sameness is real for commodity features — exactly why buy is rational there. Moat comes from data, distribution, workflow embedding, and trust — not from self-hosting the same open-weight model competitors can host.
Companies that build everything AI often ship slower and margin-worse than competitors who bought commodity layers and invested build budget in core product.
Key takeaways
- Build vs buy for AI is margin and moat — not engineering preference.
- Buy commodity capabilities; build where proprietary data and workflow differentiate.
- Model inference COGS must fit pricing at 3× projected usage before building.
- Hidden build costs: eval, incidents, model deprecation, security, opportunity cost.
- Hybrid is default: buy inference, build workflow, permissions, and product integration.
- Fine-tuning and custom RAG are build paths — exhaust cheaper levers first.
Conclusion
Build vs buy for AI features resolves to one question: if a competitor used the same vendor tomorrow, would customers still choose you? Yes — build the workflow and data loop. No — you are debating infrastructure for a commodity checkbox.
Run the margin model before the architecture review. The build meeting that skips finance repeats as the gross margin emergency next fiscal year.