Build vs Buy (API vs Self-Host)
Overview
Buy (hosted API) trades control for speed and zero GPU ops. Build (self-host / custom stack) trades engineering burden for data residency, cost at scale, and weight-level control. The right call depends on volume, compliance, and team capacity — not ideology.
When to Use
- Choosing inference stack for a new AI feature
- Finance or legal asks about data leaving your boundary
- API bill is growing faster than usage
- Skip for throwaway prototypes where only learning speed matters
Quick Reference
| Factor | Favors API | Favors self-host |
|---|
| Time to first ship | Yes | No |
| PII / regulated data | Sometimes (with BAAs) | Often |
| Request volume | Low–medium | High (cost crossover) |
| Team ML ops depth | Thin | Has on-call for GPUs |
| Model swap frequency | Want easy A/B | Can pin versions |
Implementation
- Estimate monthly tokens from realistic traffic, not peak demo load.
- Price API vs GPU at that volume including engineering time for self-host.
- Check legal — can this data be sent to a third-party API?
- Map failover — if API, multi-provider router; if self-host, redundancy and rollback.
- Default API for MVP — revisit when compliance or unit economics force it.
- Keep a provider abstraction so "buy" does not become permanent lock-in.
On This Portfolio
Copilot and assistant run through a provider router with admin-selectable models on Vercel — buy for velocity. Embeddings and content live in Supabase pgvector — build where data already lives.
Common Mistakes
- Self-hosting early to "save money" before volume justifies ops
- Ignoring residency until security review blocks launch
- Hardcoding one vendor SDK across every route
Related Skills
- Provider-agnostic abstraction layer design
- Token cost estimation & budgeting
- Multi-provider failover design