---
name: build-vs-buy
description: Use when choosing between a hosted model API and self-hosting or fine-tuning your own model.
---

# 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

1. **Estimate monthly tokens** from realistic traffic, not peak demo load.
2. **Price API vs GPU** at that volume including engineering time for self-host.
3. **Check legal** — can this data be sent to a third-party API?
4. **Map failover** — if API, multi-provider router; if self-host, redundancy and rollback.
5. **Default API for MVP** — revisit when compliance or unit economics force it.
6. **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