Build vs buy software: a decision framework for small teams
Building is rarely the default, and buying isn't always cheaper. Six questions and one spreadsheet-sized calculation settle most build-vs-buy decisions.
On this page
“Should we build it or buy it?” gets answered by instinct more often than by analysis. Engineers lean towards building; finance leans towards buying. Both are right some of the time. The way to settle it is two separate questions: is this strategic? and what does each path cost over three years?
01The short answer
- Buy when the problem is common, the tools fit your process well and you need it working soon.
- Build when the system is part of how you compete, off-the-shelf tools force you to change how you work, or per-seat pricing will outgrow a build.
- Hybrid — buy the platform, build the integrations or custom workflow on top — when the answers are mixed. This is more common than either extreme.
02Six questions that decide it
- 01How central is it to what makes you different? Competitive advantage points to build. Back-office commodity points to buy.
- 02How well do existing tools fit? If you'd have to bend your process to fit the tool, that cost is paid every day.
- 03How many systems must it connect to? Many custom integrations erode the “it just works” benefit of buying.
- 04How sensitive is the data? Strict data-residency or regulatory needs can rule vendors out.
- 05When do you need it? A deadline measured in weeks favours buying.
- 06Who will maintain it? If nobody can own a custom system after launch, buy.
03The three-year cost comparison
Compare total cost of ownership over three years, not the monthly price. For buying: setup and migration, plus seats × price, plus the annual price increases most vendors apply. For building: the build cost, plus monthly maintenance and hosting.
| Input | Buy | Build |
|---|---|---|
| Up front | $3,000 setup | $45,000 build |
| Ongoing | 25 seats × $45 / month | $900 / month maintenance |
| Price increase | 7% a year | — |
| 3-year total | ≈ $46,400 | ≈ $77,400 |
At 25 seats, buying is about $31,000 cheaper over three years. On cost alone, it's not close.
04When the numbers flip
Keep everything the same but grow the team to 120 seats. Buying now costs about $211,000 over three years; building still costs about $77,400. In this example the lines cross at roughly 43 seats — above that, the build is cheaper within three years.
Two honest caveats. Maintenance and hosting for a custom system can grow with usage too, so check that assumption. And a lower cost doesn't make building right if nobody can own it after launch.
05Hidden costs on both sides
| Buying | Building |
|---|---|
| Workarounds when the tool doesn't fit | Someone has to own it after launch |
| Price rises and plan changes | Security updates and dependency upkeep |
| Integrations and middleware | Scope that grows once people start using it |
| Data locked in the vendor's format | Time before the first version is usable |
06The hybrid path
Many of the best outcomes combine both: buy a solid platform for the standard parts — accounts, billing, a CRM — and build the pieces that are genuinely yours on top: the integrations, the automations, the customer-facing workflow. You get speed where it's cheap and control where it matters.
07Your next step
Write down the six answers, then run both cost paths in the build vs buy calculator. If building looks right, the build budget & runway calculator helps size the team and timeline. And if you want a second opinion, that's a normal first conversation for our SaaS development team.