Every growing business hits the same moment. The tools that got you here start to pinch: a CRM that needs three workarounds, a spreadsheet only one person understands, a subscription bill that grows every renewal. Someone asks the obvious question: should we just build our own?
Sometimes the answer is yes. Often it is "not yet", and occasionally it is "absolutely not". This article is the framework I use with clients to tell the difference, with real numbers on what off-the-shelf software costs in 2026 and a simple way to decide what to build, what to buy and what to connect.
Why this question is louder in 2026
Three things have changed the maths.
Companies run more tools than ever. Okta's Businesses at Work 2025 report found the average company now uses 101 apps, crossing 100 for the first time after years of flat growth. Every one of those is another login, another bill and another place your data lives.
Subscription prices are rising faster than inflation. Vertice, which tracks SaaS spend across its customers, reported SaaS inflation of 16.4% in June 2026, a record and roughly four times the US consumer price index. Big vendors are part of it: Salesforce raised list prices for its Enterprise and Unlimited editions by an average of 6% in August 2025.
Building got cheaper. In McKinsey's State of AI 2026 survey of 1,719 business leaders, 32% said their organisation had decided against buying at least one software product or feature because it could be built in-house with AI coding tools. McKinsey is careful to add that this does not mean companies should build everything themselves, and I agree.
So the question is no longer "can we afford custom software?" It is "which parts of our business deserve it?"
The one-question test
Before comparing prices, ask this:
Is this process part of how we win customers or make money, or is it the same in every company?
Email, payroll, accounting and video calls work roughly the same everywhere. Nobody chooses your company because of your payroll software. Buy those, and do not think about it again.
But the way you quote a job, schedule your crews, onboard a client or price a complex order is often exactly what makes you better than a competitor. Forcing that through a generic tool means your team adapts to the software, instead of the software adapting to the way you work. That is where custom software earns its cost.
| Usually buy | Often worth building |
|---|---|
| Email, calendar, video calls | Quoting and pricing for your specific products |
| Accounting and payroll | Scheduling with your real rules and constraints |
| Generic CRM for a simple sales process | Client portals that show your data, your way |
| Help desk for standard support | Operations dashboards across all your systems |
| Design and document tools | Workflows and approvals unique to your business |
Signs your tools are costing more than their price
The subscription fee is the visible cost. The bigger costs usually hide in your team's day:
- Data is typed in twice. The same order goes into the shop, the spreadsheet and the accounting tool, and someone reconciles the differences on Friday.
- One spreadsheet runs the business. When its owner is on holiday, nobody is quite sure what the numbers mean.
- Workarounds are normal. Every new hire is taught the "trick" for making the tool do something it was never designed for.
- Customers wait on people. A quote, booking or status update sits until someone is at a desk to push it through.
- You pay for features you don't use. The plan you need for one feature includes twenty you never touch, priced per seat.
If three or more of these are true, the real cost of your current setup is mostly in hours, not invoices.
A simple three-year cost comparison
Here is an example I walk through with clients. The numbers are illustrative, but the shape is typical.
A team of 20 pays $45 per user per month for a tool that covers most, but not all, of a core process. That is $10,800 in year one. If the price rises by 12% a year, roughly in line with recent SaaS inflation, the bill looks like this:
| Year | Subscription cost |
|---|---|
| 1 | $10,800 |
| 2 | $12,096 |
| 3 | $13,548 |
| Total | about $36,400 |
That is before the hours spent on workarounds, and before adding the next five hires at the same per-seat price.
Now flip the question: could a focused system, built around exactly that process, be built and run for less than that over three years, and save the team time on top? For a narrow internal tool or a well-scoped workflow, the answer is often yes. For a broad product like a full CRM or accounting suite, it is almost always no. That is the point of the comparison: it tells you which tools to replace, not whether to replace everything.
Remember to include the running costs of custom software honestly: hosting, monitoring, security updates and small improvements. For a typical internal system these are modest, but they are not zero.
The option most people miss: build the core, buy the rest, connect everything
The best answer is rarely "replace everything" or "keep everything". It is usually a hybrid:
- Keep the commodity tools that work fine: accounting, email, payments.
- Build the small, valuable core that the generic tools handle badly, such as your quoting engine, client portal or operations dashboard.
- Connect them so data moves on its own. Most modern tools have an API, so the new system reads from and writes to the tools you already pay for.
This approach keeps the first build small, avoids rewriting things that already work, and gets value in front of your team in weeks rather than months.
When you should not build
Custom software is the wrong call when:
- The process is still changing every month. Wait until you know how you actually want to work, or start with a lightweight prototype.
- An existing tool does 90% of the job. Configure it, add a small integration for the missing 10%, and move on.
- Nobody owns it. Custom software needs a person in your business who decides what it should do next.
- You need it tomorrow. A good first version takes weeks, not days.
A good developer should tell you this before taking your money. If someone recommends building everything from scratch without asking how your business works, get a second opinion.
How to start without a big risk
If the test points to building, keep the first step small:
- Map one process end to end. Who does what, which tools are involved, where it breaks.
- Pick the most painful part, not the whole process.
- Agree a written scope and budget for a first version that fixes just that part.
- Ship it in small pieces you can click through every week.
- Measure the hours saved, then decide what comes next.
Built this way, the first version often pays for itself in saved time before you decide on a second.
Agency or one developer?
For large, multi-team programmes, an agency can make sense. For most small and mid-sized businesses, one experienced developer is faster and cheaper, because your budget pays for the engineering rather than account managers, project managers and office overhead. You talk to the person writing the code, decisions take hours instead of meetings, and if the code is documented and set up in your name, adding more developers later is straightforward.
The bottom line
Buy the tools that are the same in every company. Build the small part of your business that makes you different. Connect everything so your team stops copying data between systems. And run the three-year numbers before deciding, because the cheapest option on day one is not always the cheapest by year three.
If you are weighing a build-or-buy decision right now, I can look at your current tools and tell you honestly what is worth building, what to keep and what it would cost. Tell me about your setup and I will reply within 24 hours. You can also read more about how I approach custom software development.