Build vs buy: how to actually decide
Buy, unless the process you are automating is the thing that differentiates you, the off-the-shelf option needs so much configuration that you are effectively programming it anyway, or per-seat licence costs have grown past the cost of ownership. Those are the three cases where building wins. Everything else, buy — and be suspicious of any agency that tells you otherwise, since they are paid to build.
Why buying wins more often than agencies admit
For accounting, payroll, email, helpdesk and general CRM, a product exists that has absorbed thousands of engineer-years and the accumulated edge cases of thousands of customers. You will not out-build it, and your business is almost certainly not special in that domain.
Buying also transfers the maintenance burden. Someone else patches the dependencies, handles the platform migration and answers the security questionnaire. That is worth real money and it never appears in a build-versus-buy spreadsheet.
The three cases where building wins
The first is differentiation. If the process is how you compete — your specific underwriting logic, your particular clinical workflow, the thing customers choose you for — encoding it in someone else's product means competing on their roadmap.
The second is configuration overrun. When fitting the product requires custom fields, scripting, integration middleware and a consultant, you are already programming, just in a worse language with a licence fee attached.
The third is licence economics. A per-seat SaaS cost across a growing team is a recurring expense that never stops and never becomes an asset. At some headcount the arithmetic flips. Work out where that point is before you reach it, not after.
| Consideration | Favours buying | Favours building |
|---|---|---|
| Is the process a differentiator? | No — it is table stakes | Yes — it is how you compete |
| Fit without customisation | Good out of the box | Needs scripting and middleware |
| Cost shape | Predictable subscription | Capital cost you own |
| Time to value | Days | Weeks to months |
| Who maintains it | The vendor | You, permanently |
| Data ownership and export | Check the exit terms carefully | Yours by construction |
The comparison most people get wrong
Build-versus-buy analyses usually compare a build quote against a subscription price and stop there. Both sides of that comparison are incomplete.
Buying carries integration work, data migration, admin time, and switching cost if you ever leave — check the export terms before you sign, because "you can export your data" and "you can export your data in a form another system can read" are different sentences.
Building carries hosting, monitoring, dependency updates, security patching and the occasional platform migration. Custom software is not a building you erect once; it is closer to a vehicle that needs servicing. Budget accordingly or it will decay.
The hybrid that usually wins
The strongest answer is frequently neither pure option: buy the commodity, build the differentiator, and integrate them.
Use the established product for accounting, email and CRM. Build the one workflow that is genuinely yours. Connect them through an API. You get maintained software where maintenance is someone else's problem, and bespoke software exactly where it earns its cost.
The main risk to manage is integration fragility — vendor APIs change and rate-limit. Design for those failures rather than assuming they will not happen.
Frequently asked
Should I build or buy software?
Buy, unless one of three things is true: the process is how you differentiate from competitors, fitting the off-the-shelf product requires so much configuration that you are effectively programming it anyway, or per-seat licence costs have grown past the cost of owning equivalent software. Otherwise an existing product will beat what you can build.
When does custom software become cheaper than SaaS?
When the recurring per-seat cost across your team exceeds the amortised cost of building and maintaining the equivalent. The crossover depends on headcount, licence price and how much maintenance the custom system will need — work out where it sits for you before you reach it rather than after.
What do people forget in a build vs buy comparison?
On the buy side: integration work, data migration, admin time and switching cost if you leave. On the build side: hosting, monitoring, dependency updates, security patching and eventual platform migrations. Comparing a build quote against a subscription price alone misses most of both.
Can we do both?
Usually yes, and it is often the best answer — buy the commodity software, build only the workflow that differentiates you, and integrate them by API. The thing to design carefully is the integration, since vendor APIs change and rate-limit.
Related
Want this built?
Tell us what you are trying to ship and we will tell you honestly whether we are the right team for it.