Build vs Buy for Software: A Decision Framework With Examples
Build software when it's part of what customers pay you for, and buy it when customers simply expect it to work. That single rule settles most decisions, and the five questions below handle the rest.
The mistake to avoid is comparing the vendor's price with the cost of writing version one. Building is cheap to start and expensive to own. Buying is easy to start and can be hard to leave. A fair comparison covers years, not weeks.
How do you decide whether to build or buy?
Work through these five questions in order and write down the answer to each:
- Is this a source of customer value or a cost of doing business? Search relevance in a search product is core. Password reset is not.
- Does a good-enough product exist for our actual requirements? List your requirements first, then test vendors against them, not against their marketing.
- What is the cost over three years? Include engineering time to build, maintain, secure and staff on-call for it.
- How hard is it to switch? Check data export, standard formats and contract terms.
- Does it touch sensitive data or a critical path? That raises the bar for both options and changes who must review it.
If the first answer is 'core' and the second is 'no', build. If the first is 'cost of doing business' and the second is 'yes', buy.
What does the real cost of building include?
Engineers usually quote the initial build. The bill that follows is larger and mostly invisible: bug fixes, upgrades, security patches, documentation, onboarding new engineers into the system and handling incidents at night.
For example, say a team builds its own notification system in six weeks. Over the next two years it will need channel changes, deliverability fixes, unsubscribe compliance and scaling work. Add up the recurring engineering time and compare it with a subscription. Also count what those engineers didn't build for customers in that time.
Software you buy has its own hidden costs: integration work, per-seat or usage growth as you scale, and the time spent working around gaps. Model usage at two or three times today's volume and see whether the price still holds. If it's an infrastructure item, one outside reference is that median hosting spend at private B2B SaaS companies is 5 percent of ARR1. It doesn't include engineer time, so count that separately.
A scoring worksheet you can copy into a spreadsheet
Give each option a score from one to five on each row, weight the rows by how much they matter to you, and total them:
- Fit to your required features. Does it do the job without workarounds?
- Differentiation. Would owning it change how customers see you?
- Three-year cost. Including maintenance and people.
- Time to first value. Weeks to something working in production.
- Switching cost. How painful is leaving?
- Security and compliance effort. Reviews, audits and data handling.
Don't treat the total as an answer. Treat it as a way to expose where the team disagrees. If one person scores differentiation at five and another at two, you've found the real debate, and it's worth having out loud.
Three worked examples
Authentication. Almost always buy or use a well-maintained open-source component. Mistakes here cause breaches, and customers expect it to just work.
Billing logic for a usage-based product. Buy the payment processing, but the pricing rules may be core. The common answer is a hybrid: use a vendor for payments and invoices, and own the code that turns your product's usage into a charge.
A recommendation engine at a media company. This is what customers come for, so it's likely core. Build it, but buy the infrastructure underneath.
The pattern is that most decisions split the problem: buy the commodity layer, build the layer that differentiates. Ask which part of the problem you're being asked to decide on.
How to reverse a decision that's going badly
Set a review date when you decide, so you check your assumptions with real data. If you built something that has become a distraction, look at whether a vendor now meets your requirements and what migration would cost. If you bought something that is limiting you, check the contract's exit terms and export options first.
The technology roadmap worksheet is a good place to record these decisions with owners and review dates. If the decision involves spending across several tools, the IT spend per employee benchmark can help you check whether the total is reasonable.
What Good Looks Like
Each build or buy decision is written down with its requirements, a three-year cost estimate, an exit plan and a date to revisit it.
Building The Capability (5-Stage Skill Ladder)
How to Get Started
Frequently Asked Questions
When should a startup build instead of buy?
Build when the capability is central to why customers choose you and no vendor meets your needs. Buy for anything customers assume works, such as authentication, email delivery or payments. Early on, buying is usually faster, and you can replace it later if it becomes a constraint.
How do I compare the cost of building and buying?
Estimate engineering time to build, then add ongoing maintenance, security, on-call and hosting over three years. Compare that total with the vendor's subscription at your expected usage two or three times higher. Include integration effort and the opportunity cost of what engineers won't build meanwhile.
What is vendor lock-in and how do I limit it?
Lock-in means switching costs are so high you can't leave. Limit it by keeping data exportable, using standard formats and APIs where possible, wrapping the vendor behind your own interface and reading the contract's exit and data-return terms before signing.
Can I start with a vendor and build later?
Yes, and it's often the better path. Buying gets you working software quickly and shows what you truly need. Put the vendor behind a thin interface in your code so a later replacement, in-house or another vendor, touches a small part of the system.
Sources
Where we quote a benchmark, we show its source. Other figures in this guide are estimates or general guidance, so check them against your own numbers.
- Hosting/cloud infrastructure spend as % of ARR (median, private B2B SaaS). SaaS Capital 2026 Spending Benchmarks for Private B2B SaaS Companies (15th annual survey, 1,000+ companies), 2026.
Related Guides
Technology Roadmap for Non-Technical Founders, Step by Step
Build a technology roadmap without writing code: tie each engineering item to a business goal, a risk and an owner, then check in monthly and re-plan quarterly.
How to Calculate IT Spend per Employee and Judge If It's Reasonable
Work out your IT spend per employee, decide what counts, split it into buckets and compare it against your own trend and the few benchmarks that hold up.
Technical Due Diligence Checklist for Buying a Software Company
A buyer-side technical due diligence checklist: code, security, infrastructure, people and licensing, with red flags and how to score what you find.
DORA Metrics for a Small Engineering Team, Without the Dashboard Sprawl
How a team of five to fifteen engineers can track the four DORA metrics, pull the data from tools you already use and avoid the common misreadings.
Fractional CTO or Technical Co-Founder: How to Choose
Compare a fractional CTO and a technical co-founder on equity, commitment, cost and control, with a decision guide based on your stage and product.
Questions to Ask a Dev Agency Before You Sign
Twenty-plus questions to ask a software development agency before hiring, grouped by ownership, process, security and exit, with what good answers sound like.