Build vs Buy vs SaaS
TCO, vendor lock-in risk, integration effort, strategic alignment
The build vs buy vs SaaS decision is one of the highest-leverage architectural choices because it determines long-term cost structure, team cognitive load, and vendor dependency. Total Cost of Ownership (TCO) must include not just licensing but engineering time, operational burden, migration costs, and opportunity cost of not building differentiating features. Vendor lock-in risk varies: deep API integration with proprietary features creates high switching costs, while standard-protocol integrations (OAuth, S3-compatible APIs) reduce lock-in. The decision should align with strategic differentiation: build what makes you uniquely competitive, buy or use SaaS for everything else.
Key Points
- Build: justified only when the capability is a core differentiator, no adequate market solution exists, or compliance requirements prohibit third-party data processing
- Buy (licensed software): on-premise or self-managed; suits regulated industries needing data sovereignty; includes vendor support but requires internal ops expertise
- SaaS: fastest time-to-value, zero ops overhead, but data leaves your perimeter; evaluate: SOC 2 Type II certification, data residency options, uptime SLA, exit strategy (data export capability)
- TCO components: licensing/subscription cost + integration engineering cost + ongoing maintenance cost + migration/exit cost + productivity cost of operational incidents caused by vendor
- Vendor lock-in mitigation: prefer open standards (OpenID Connect over proprietary SSO, S3-compatible APIs over proprietary object storage APIs, OpenTelemetry over vendor-specific agents)
- Procurement risk: single-vendor dependency for a critical capability creates existential risk; maintain a shortlist of alternative vendors and validate them annually (RFP readiness)
- Build vs buy signal: if a SaaS vendor's product roadmap is 80% of what you need and the remaining 20% is commodity, buy and accept the gap rather than building the 80% yourself
- The "boring technology" principle (Dan McKinley): choose established, well-understood tools over cutting-edge ones unless the problem domain specifically requires innovation — operational predictability has high business value
| Decision Factor | Build | Buy (Licensed/OSS) | SaaS |
|---|---|---|---|
| Time to Value | 6–18 months for complex capabilities | 1–3 months (integration + learning curve) | 1–4 weeks (configuration + integration) |
| Upfront Cost | High (engineering salaries, infra) | Medium (license fee + integration engineering) | Low (subscription, often per-user or per-usage) |
| 3-Year TCO | Highest if not a differentiator; lowest if core IP | Medium; predictable licensing; ops cost significant | Predictable; can escalate at scale (per-seat pricing) |
| Operational Burden | Full: your team owns upgrades, DR, scaling, security patches | High: self-managed OSS (e.g., Kafka, Elasticsearch) requires significant ops expertise | None: vendor manages uptime, scaling, security; you manage configuration |
| Customization | Unlimited: you own the code | Limited to configuration and plugin APIs | Low: vendor roadmap determines feature availability |
| Vendor Lock-in Risk | None (you own it, but has talent/knowledge risk) | Low-Medium: open standards reduce switching cost | High if proprietary APIs; mitigated by abstraction layers |
| Data Control | Full: data stays in your environment | Full: self-hosted | Partial: data processed by vendor; evaluate DPA, data residency, encryption-at-rest controls |
| Best For | Core differentiating capability (recommendation engine, fraud detection, core product) | Regulated industries needing data sovereignty (Kafka, PostgreSQL, Kubernetes) | Non-differentiating capabilities (email delivery, CRM, HR systems, monitoring) |
Real-World Example
Dropbox migrated off AWS S3 in 2016 (for their primary storage, not all services) and built their own distributed storage system (Magic Pocket) — a build decision justified because storage IS their core product differentiator and at their scale, saving $75M/year in cloud costs made the multi-year engineering investment worthwhile.