Decision guide
Build vs Buy vs Open Source
Should your team build this capability, buy it, or adopt open source?
Side by side
| Criterion | Build | Buy (SaaS / vendor) | Open source (self-hosted) |
|---|---|---|---|
| Upfront cost | High (engineering time) | Integration and procurement | Setup and integration |
| Ongoing cost | Maintenance, on-call, features, security | Licence growth, vendor management | Operations, upgrades, patches |
| Control and fit | Full | Limited to the product | High (can fork) |
| Lock-in / exit cost | Low (yours) but knowledge risk | Medium to high; wrap it | Low to medium |
| Time to value | Slowest | Fastest | Medium |
When to choose each
Build
Design and operate the capability in-house.
Choose when
- It differentiates your product
- No product fits your requirements
- You can staff its maintenance for years
Avoid when
- It's a commodity (auth, flags, email, observability)
- Nobody will own it after version one
Buy (SaaS / vendor)
Use a commercial product, integrated behind an internal interface.
Choose when
- Non-differentiating capability
- You need it fast and reliably
- Vendor meets security, data-location and SLA needs
Avoid when
- Pricing at your scale is prohibitive
- Data can't leave your environment
- No export or exit path
Open source (self-hosted)
Run an open-source project yourself.
Choose when
- You need control or self-hosting
- A healthy project exists
- You have operational capacity
Avoid when
- You can't keep up with upgrades and security patches
- The project is poorly maintained
Verdict
Build what differentiates you, buy what doesn't. Compare three-year total cost of ownership — including maintenance, on-call and opportunity cost — check security, data location and exit path, and prefer buy and wrap behind an internal interface. Record the decision and its assumptions in an ADR.