After two decades of building software, I’ve seen companies make this decision well and I’ve seen them get it catastrophically wrong. The difference often comes down to asking the right questions upfront.
The Real Question
Most teams frame this as a technical decision. It’s not. It’s a business decision with technical constraints.
The real question isn’t “can we build this?” — you probably can. The question is “should we, and what’s the true cost?”
The Framework
I use a simple mental model with three factors:
1. Is This a Competitive Advantage?
If the software directly differentiates your business, lean toward building. If it’s infrastructure that every company needs, lean toward buying or open source.
Build: Your proprietary trading algorithm, your unique customer experience, the thing that makes customers choose you over competitors.
Buy/Open Source: Authentication, payment processing, email delivery, logging. You’re not in the authentication business.
2. What’s the Total Cost of Ownership?
Everyone underestimates the cost of building. It’s not just initial development — it’s:
- Ongoing maintenance (plan for 20% of initial cost annually)
- Security patches and updates
- Scaling as you grow
- Documentation and knowledge transfer
- The opportunity cost of your team not building revenue-generating features
A $50k “build” decision often becomes $200k over five years. That enterprise SaaS license doesn’t look so expensive anymore.
But — vendor costs compound too. That $500/month tool becomes $2,000/month when you need more seats, then $5,000/month for the enterprise tier with the features you actually need. I’ve seen companies trapped in vendor relationships that cost more than building would have.
Run the numbers for 3-5 years, not just year one.
3. What’s the Risk Profile?
Open source is free until it isn’t. Consider:
- Maintenance risk: Is the project actively maintained? One maintainer or a healthy community?
- Security risk: How quickly are vulnerabilities patched? Who’s responsible when there’s a breach?
- Compliance risk: Does the license work for your use case? GPL in your proprietary product is a landmine.
- Integration risk: How much custom work to make it fit your stack?
Commercial software shifts some of this risk to the vendor — that’s part of what you’re paying for. Custom software puts all the risk on you, but also all the control.
The Decision Matrix
| Scenario | Recommendation |
|---|---|
| Core differentiator, long-term investment | Build |
| Commodity function, predictable needs | Buy |
| Commodity function, technical team, cost-sensitive | Open Source |
| Competitive advantage, but need speed to market | Buy now, build later |
| Uncertain requirements, exploring | Open Source or low-commitment SaaS |
The Hidden Option: Build on Top
The best solutions often combine approaches:
- Open source foundation + custom layer for your specific needs
- Commercial platform + custom integrations
- Build the core IP, buy everything else
This is where experience matters. Knowing which components to own and which to outsource is the difference between a lean, maintainable system and an expensive mess.
When Companies Get This Wrong
Over-building: Engineering teams love building. That’s the job. But building a custom CMS when WordPress exists, or a custom auth system when Auth0 exists, is burning money and introducing security risk.
Over-buying: Enterprise sales teams are very good at their jobs. I’ve seen companies paying six figures annually for software they use 10% of, when a $50/month tool or open source alternative would cover their actual needs.
Underestimating integration: “We’ll just use this open source project” becomes six months of customization, then ongoing maintenance that nobody budgeted for. The software was free; the implementation wasn’t.
Ignoring security: That unmaintained npm package with 47 GitHub stars? That self-hosted open source tool nobody’s updating? These become liabilities. Fast.
The Honest Answer
There’s no universal right answer. The best choice depends on your team’s capabilities, your budget, your timeline, and your risk tolerance.
What I can tell you from experience: the companies that get this right treat it as a strategic decision, not a technical one. They invest time upfront to understand the true costs and tradeoffs. They revisit the decision as circumstances change.
And often, they bring in outside perspective — because when you’re deep in the weeds of your own business, it’s hard to see the full picture.
At Aitchdien, we help companies navigate these decisions and implement solutions that balance cost, security, and maintainability. If you’re facing a build-vs-buy decision and want an experienced perspective, let’s talk.