Build or buy: how to decide honestly
The question is asked as a budget comparison and decided badly as a result. Licence cost against development cost misses almost everything that matters.
Buy when the process is ordinary
Accounting, payroll, email, customer relationship management, helpdesk ticketing. Thousands of companies do these almost identically. A packaged product has absorbed years of edge cases you have not thought of, and it comes with a support contract, a compliance roadmap and other people's bug reports.
Building your own version of a solved problem means paying to rediscover it.
Build when the process is the differentiator
If the way you do something is why customers choose you, packaged software will make you average at it. Signs you are in this territory:
- Your team maintains elaborate spreadsheets to work around the product you bought
- You pay for eleven modules and use two
- Your competitors cannot easily copy this part of your operation
- The workflow genuinely does not exist in any product, because you invented it
The costs each side hides
Buying hides: per-user pricing that scales badly, integration work between products, annual increases, migration cost when you outgrow it, and the constraint of a roadmap you do not control.
Building hides: maintenance forever, the bus factor of one developer, security patching, the second system nobody scoped, and the fact that version one is roughly forty percent of total lifetime cost.
The answer most companies need
Buy the ordinary parts. Build the thin layer that is genuinely yours. Integrate them properly.
That usually means a packaged accounting system, a packaged CRM, and one custom application handling the workflow specific to your business — connected by integrations rather than by staff copying between them.
Before commissioning anything
Write down what the process does today, including every exception. If that document is short and unremarkable, buy something. If it is long, full of judgement calls, and describes something no vendor sells — build it, and budget for maintaining it.
We work through this in software development engagements.
