Start from the assumption that you should buy
For most business functions — accounting, payroll, email, CRM, helpdesk — a mature product exists, thousands of companies have already found its bugs, and the vendor employs more engineers on it than you could justify hiring. Building your own is almost always a mistake in these categories.
The interesting question is not whether off-the-shelf software is good. It is whether the specific process you are automating is one where being the same as everyone else is fine.
Three questions that decide it
Is this process how you compete?
If the process is a differentiator — how you price, how you route, how you match, how you underwrite — then a generic tool forces you to compete the same way as everyone who bought it. That is the strongest case for building.
If the process is the same as it is at every other company in your sector, buy it.
How much configuration would it take?
There is a middle zone where a platform technically supports what you need, but only through a stack of custom fields, third-party add-ons and consultants. This is where costs hide. A platform reshaped far enough from its intended use ends up with the maintenance burden of custom software and none of the control.
A useful signal: if the implementation quote is larger than the licence cost, you are in that zone and should compare the two options seriously.
What is the total cost over five years?
Compare honestly. Off-the-shelf: licences per user per month, growing as you hire; implementation; integration work; annual price increases; and the migration cost if you ever leave. Custom: a larger upfront build; hosting; and ongoing maintenance, realistically fifteen to twenty-five percent of the build cost each year.
For a small team, buying almost always wins. Somewhere between thirty and a hundred users — depending on the per-seat price — the lines cross. Do that arithmetic before the decision, not after.
The hybrid answer is often correct
The most common good outcome is neither pure option. Buy the commodity systems, build the layer that makes your operation specific, and integrate them through APIs. You keep the vendor's reliability where it does not matter that you are ordinary, and you control the part that does.
This is what most well-run mid-sized companies actually run: standard accounting and CRM, plus one or two internal systems that encode how they specifically work.
Warning signs that you have outgrown a platform
Watch for these: staff maintaining shadow spreadsheets alongside the official system; a growing number of exports feeding a manual process; a recurring feature request that the vendor has declined for two years; per-seat costs rising faster than headcount value; and integration work that keeps breaking on vendor updates.
Any two of these together is worth a proper build-versus-buy analysis.
If you decide to build
Scope the first release brutally. The failure mode of custom software is not bad code — it is a first version that tried to replace everything at once and shipped eighteen months late. Pick the single workflow that hurts most, ship it, get it used, and expand from there.
And insist on owning the repository, the infrastructure and the documentation from the first commit. The point of building is control. An arrangement that leaves you dependent on one supplier has given away the only advantage custom software had.