Every technology capability your product needs can be built from scratch, purchased from a vendor, or assembled from open-source components. Most organisations make this decision by instinct ("we're a tech company — we build things"), by inertia ("we've always used this vendor"), or by whoever advocated loudest in a meeting.
None of those are good reasons.
The build vs. buy vs. open-source decision is one of the most consequential choices a technology organisation makes — it determines engineering headcount, cost structure, competitive differentiation, and long-term risk profile. It deserves a framework.
The hidden assumption most companies make
The most common failure mode is treating "build" as the default for anything that seems important. Technology teams often conflate "this is important" with "we should build it ourselves." These are completely different questions. Importance determines priority; the build/buy/OSS decision determines method.
The Three Options Defined
Build: You design, develop, and maintain the capability entirely in-house. Full control, full cost, full responsibility.
Buy (SaaS/Commercial): You license a commercial product and integrate it. You give up customisation in exchange for removing development and maintenance obligations.
Open Source: You adopt a community-maintained framework or library and take responsibility for integration, configuration, and maintenance of that specific component. You get the source code and a community but inherit operational responsibility.
Note: these are often combined. You might build a custom application layer on top of an open-source framework, deployed on a commercial cloud, integrated with a SaaS analytics tool. The question is which option applies to each capability.
The Decision Framework
Ask these five questions for each capability you're evaluating:
If the capability is core to your value proposition — what makes you different from competitors — building it gives you a moat. If a competitor could subscribe to the same SaaS and have identical capability, buying is fine. Your CRM is not a differentiator. Your recommendation algorithm might be.
Build costs are frequently underestimated. Include: initial development, ongoing maintenance (typically 20–30% of initial cost per year), security patching, scaling work, and the opportunity cost of engineering time not spent on product. Compare this honest TCO against vendor pricing.
If multiple mature vendors serve this need and cover 80%+ of your requirements, the case for building is weak. If no vendor covers your specific use case well, or vendor coverage is superficial, the case for building strengthens.
Commercial SaaS introduces pricing risk (vendor increases prices), availability risk (vendor outages affect your product), data portability risk (vendor lock-in), and viability risk (vendor is acquired or shuts down).
Underestimating the ongoing maintenance obligation is the most common build mistake. Building a payment processing system requires PCI compliance, fraud detection, dispute management, and regulatory updates — forever.
When to Build
Build when all three of these are true:
- The capability is central to your competitive differentiation
- No commercial or open-source alternative covers your requirements adequately
- You have — and plan to maintain — the engineering capacity to build and maintain it properly
Classic "build" decisions:
- Your core machine learning model (if it's your product's primary value driver)
- A domain-specific algorithm that no vendor has productised
- A customer-facing experience that is unique to your brand
The premature build trap
Early-stage companies often build things they should buy because the founder has an opinion about the right way to do it. Payment processing, email delivery, authentication, customer support tools, analytics dashboards, and internal HR systems are almost never worth building. Every hour spent on these is an hour not spent on the thing that actually differentiates you.
When to Buy (SaaS)
Buy when:
- The capability is a commodity (authentication, email, CRM, HRIS, billing, support)
- A vendor covers 80%+ of your requirements with a mature product
- The vendor's SLA and reliability exceed what you'd achieve building it yourself
- The total cost of ownership favours the vendor over a 3-year horizon
Classic "buy" decisions:
- Authentication and identity (Auth0, Okta — don't build your own auth)
- Email delivery (SendGrid, Postmark — the deliverability problem alone is worth paying for)
- Payment processing (Stripe, Adyen — the compliance overhead of building this is extraordinary)
- Customer support (Zendesk, Intercom — commodity, well-served market)
- Analytics (Mixpanel, Amplitude — unless analytics is your product)
The rule of thumb: if you could describe your requirement to a SaaS vendor's sales team and they'd say "yes, we do that" — buy.
When to Use Open Source
Open source is appropriate when:
- A mature, well-maintained project covers your technical requirement
- You're willing to own the operational responsibility for deployment, configuration, and updates
- The community is active and the project has long-term viability
- The licensing is compatible with your commercial model
Classic "open source" decisions:
- Application frameworks (React, Next.js, Django, Spring — the baseline)
- Databases (PostgreSQL, Redis, MongoDB)
- Observability tooling (Prometheus, Grafana, OpenTelemetry)
- Infrastructure tooling (Terraform, Kubernetes, Helm)
- Message brokers (Kafka, RabbitMQ)
The open source risks to manage:
- Licensing: GPL, AGPL, and SSPL licenses have commercial implications. Review every dependency's license before production use.
- Supply chain: Open-source dependencies are an attack vector. Implement Software Composition Analysis (SCA) to track vulnerabilities in your dependency tree.
- Abandonment: Projects are sometimes abandoned. Assess community health before committing to a dependency: commit frequency, number of contributors, issue response time.
The Matrix
| Criterion | Build | Buy | Open Source |
|---|---|---|---|
| Differentiates you from competitors | ✓ | ✗ | △ |
| Time to first value | Slowest | Fastest | Fast |
| Ongoing maintenance cost | High | Low (opex) | Medium |
| Customisation freedom | Full | Limited | High |
| Vendor lock-in risk | None | High | Low |
| Scales with your requirements | Yes | Depends on vendor | Yes |
| Regulatory/security control | Full | Shared | Full |
The Hybrid Reality
In practice, every production system is a hybrid. The question isn't "should we build everything or buy everything?" It's "which layer of this capability is truly differentiated, and what's the right sourcing decision for each layer?"
A common pattern for a B2B SaaS product:
- Authentication: Buy (Auth0 / Okta) — commodity, high-security-requirement, well-served market
- Infrastructure: Open source on commercial cloud (Kubernetes on AKS, Terraform for IaC) — standard tooling, your team's expertise
- Core product logic: Build — this is your differentiation
- Analytics: Buy (Amplitude / Mixpanel) until analytics becomes a product feature, then reconsider
- Support tooling: Buy (Intercom) — commodity
- Billing: Buy (Stripe) — the compliance overhead of building this justifies the 2.9% fee
Every decision should be deliberate, documented, and revisited annually as the market evolves, your team grows, and your requirements change.
Build vs. buy decisions are some of the most strategically important calls a technology organisation makes. If you'd like a structured review of your current sourcing decisions, let's talk.