We build custom software for a living, so the useful thing we can offer here is the case against doing it. Most businesses should buy most of their software, and we tell people that regularly.
The decision is not really about cost. It is about whether the way you work is generic or whether it is the thing that makes you competitive.
Accounting, payroll, email, calendars, helpdesks and most CRM work are solved problems. Thousands of businesses need the same thing, the products are mature, and someone else pays for the maintenance, the security patching and the compliance changes. Building your own version of any of these is almost always a poor use of money.
There is a second, less obvious argument for buying: staff already know how to use it. Hiring someone who has used your accounting package before is easier than training everyone on software that exists only inside your company.
If the way you quote, schedule, price or fulfil work is why customers choose you, forcing that into someone else's workflow slowly erodes the thing you were good at. That is the clearest case for building.
The other clear case is integration. When five systems each hold part of the truth and staff move data between them by hand, the cost is not the licences. It is the errors, the delay, and the fact that nobody can answer a simple question about the business without opening four tabs.
One or two of these is normal. Four or five, consistently, and you are already paying for custom software. You are just paying for it in staff time rather than in a build.
Off-the-shelf is cheaper up front and often not cheaper over five years, because per-seat pricing grows with your headcount while a build is mostly a one-off cost plus maintenance. The lines cross at some point. Where they cross depends on your team size and how many products you are stacking.
Two things people leave out of the comparison. On the buy side: the staff time spent on workarounds, which is real money and usually invisible because nobody invoices for it. On the build side: maintenance, which is not optional. Budget 15 to 20 percent of the build cost per year to keep custom software healthy, and treat anyone who omits that from a proposal with suspicion.
In practice the sensible outcome is rarely all of one or all of the other. Keep buying the generic things, because there is no advantage in owning your own payroll system. Build the one part that is genuinely yours, and integrate it with what you already have.
That is a much smaller project than replacing everything, it can be paid for out of operating budget rather than a capital decision, and it can be built in stages so you find out early whether it is working. It is also easier to abandon if you are wrong, which is worth more than it sounds.
Write down the process you are trying to support, as it actually happens rather than as the manual describes it. Then evaluate products against that document. About half the time this exercise finds a product that fits after all, and the half hour spent writing it down saves a six-figure decision.
If nothing fits, you now have the beginning of a scope. And if you build, insist on owning the code, the IP and the infrastructure outright. Software you cannot take elsewhere is a subscription with extra steps.
We start every engagement with strategy for this reason: sometimes the honest recommendation is that you do not need us. Read about how we approach tech strategy, or see how we build custom software if you already know that is the way you are going. For smaller teams, our small business services start with a tech health check that answers exactly this question. Get in touch and we will give you a straight opinion.
Up front, almost always. Over five years, not necessarily. Per-seat licensing scales with your headcount while a build is mostly a one-off cost, so the lines cross at some point. Where they cross depends on your team size and how many tools you are paying for.
When the job is genuinely the same as everyone else's. Accounting, payroll, email and CRM are solved problems and building your own is rarely a good use of money.
Exports and re-imports between systems, a spreadsheet that quietly became critical infrastructure, paying for features you do not use to reach one you need, or a process that is your competitive edge being forced into someone else's workflow.