A business should build custom software when its off-the-shelf tools cost more in workarounds, retyping, licences and lost work than a focused build would, and when the process involved is specific to how it operates. The clearest sign is simple: your team keeps a spreadsheet alongside a tool you already pay for.
That does not mean every frustration with a SaaS tool justifies a build. Plenty of problems are fixed more cheaply by configuring what you have or connecting two systems. This guide covers the seven signs that you have outgrown off-the-shelf software, the cases where building is the wrong call, and a scorecard to help you decide.
Seven signs you have outgrown off-the-shelf software
In short: when your team works around the software instead of through it, the software has stopped fitting the business.
Off-the-shelf software is designed for the average customer in its market. That is why it is quick to start and cheap at first. As a business grows, it adds people, services, pricing rules and exceptions, and its way of working drifts away from that average. The tool stays where it was.
The gap rarely shows up as one big failure. It shows up as small workarounds: an extra spreadsheet, another subscription, a weekly export, a colleague who “just knows” how to fix the numbers. Each is cheap on its own. Together they become a hidden running cost that nobody budgets for, and a risk when the person who knows the workaround is on holiday or leaves.
One sign on its own is usually a configuration problem. Three or four together, especially the first two, usually mean you have outgrown SaaS tools built for a broader market.
1. You pay for too many SaaS tools
A CRM, a project tool, a form builder, a scheduling app, a reporting add-on and a document signer, each solving one slice of the same process. Every one has its own login, its own copy of the customer and its own monthly bill. Nobody can say which system holds the truth.
Tool sprawl rarely happens by design. Each tool was bought to fix a gap the previous one left. The total cost and the time spent switching between them are what tell you the stack no longer fits.
2. Spreadsheets run alongside the tools you pay for
This is the most reliable signal of all. If staff export from the CRM to a spreadsheet to plan the week, or keep a private tracker because the job tool cannot show what they need, the tool does not match the work.
That spreadsheet is not laziness. It is, quite literally, a specification for the system you should have: the columns are your data model and the formulas are your business rules.
3. People retype the same information
An enquiry comes in by e-mail and is typed into the CRM. When it is won, it is typed into the job system. When the job is done, it is typed into the accounting package. Each retype costs minutes, and each one is a chance for an error that someone later has to find.
Sometimes this is purely an integration gap, and business process automation fixes it without any new system. If the retyping exists because no tool models your process properly, automation only hides the problem.
4. Integrations are missing, fragile or expensive
Off-the-shelf tools connect well to other popular tools and poorly to anything bespoke: your pricing engine, a supplier portal, an industry system, an older database. Typical symptoms are a chain of automation recipes that breaks when one vendor changes something, or an integration that only exists on the top pricing tier.
When two systems must behave as one, for example a won deal that should create the job, reserve stock and raise the invoice, a custom layer between them is often cheaper and more reliable. Our guide to custom software integrations explains the options.
5. Reporting is slow or untrustworthy
If a monthly report means a day of exporting, merging and correcting spreadsheets, your data lives in too many places. If two managers bring different numbers to the same meeting, nobody trusts any of it.
Good reporting is a by-product of data living in one consistent structure. Off-the-shelf tools report well on what they hold. They struggle with questions that cross tools, such as true margin per job or conversion by lead source through to payment.
6. Per-seat costs are outgrowing the business
Per-user pricing is reasonable at 8 users and painful at 60, especially when you pay for premium tiers to get one feature. Illustrative example: 30 users on tools costing £40 ($50) per user per month is £14,400 ($18,000) a year. Hire 15 more and it becomes £21,600 ($27,000), before any renewal increase.
When the subscription line grows faster than revenue, you are renting something you could own. Our custom software vs off-the-shelf software comparison works through the three- and five-year totals.
7. The tool forces you to change how you win work
The most expensive sign is also the least visible. A trading company bends its costing logic to fit a generic quote template. A clinic changes its booking rules because the scheduler cannot express them. A contractor stops tracking variations because the job tool has no place for them.
If the way you price, sell or deliver is part of why customers choose you, a tool that flattens it is costing you more than its subscription.
When you should not build custom software
In short: do not build for standard jobs, for configuration problems, or without someone to own the process.
Custom software is the wrong answer more often than people selling it admit. Do not build in these situations:
Accounting, payroll, e-mail and documents are solved problems. In the UK, VAT-registered businesses must use software compatible with Making Tax Digital to keep VAT records and file returns. Keep a compatible accounting package and feed it from your other systems.
Many “the CRM does not work” problems are untouched default settings, missing fields and no training. A few days of configuration costs far less than a build.
If each tool works but people move data between them, an integration or automation is usually enough. Build only if the tools themselves do not fit.
If no one internally can explain the process and review progress every week, a custom system will encode confusion. Define the process first.
A focused custom tool takes weeks, not days. If the deadline is immediate, buy something now and plan the build properly.
For a handful of users on a standard process, subscriptions usually stay cheaper than building and maintaining your own system.
The business software solutions guide lists the categories most SMEs should simply buy, and the order in which to add them.
A build vs buy scorecard
In short: score eight statements from 0 to 2; the total tells you whether to stay, connect or build.
Score each statement honestly for the process you are thinking about, not the whole business. 0 means not true, 1 means partly true, 2 means clearly true.
| # | Statement | Score (0–2) |
|---|---|---|
| 1 | Staff keep a spreadsheet or tracker alongside a tool we pay for, for this process | |
| 2 | The same data is typed into two or more systems | |
| 3 | A report we rely on takes more than half a day to put together by hand | |
| 4 | The integrations we need do not exist, keep breaking, or sit on a top pricing tier | |
| 5 | Subscription costs for this process will at least double in three years as we hire | |
| 6 | The process is part of how we win or deliver work, not a standard back-office job | |
| 7 | We have already changed how we work to fit a tool, and it has cost us work or margin | |
| 8 | We can describe the process step by step, and one person internally owns it |
Two overrides. If statement 8 scores 0, fix the process definition before building anything, whatever the total. And if you need a working answer within days, buy now and treat the score as the case for a build later.
The scorecard tells you whether building is worth exploring. For the side-by-side comparison of cost model, ownership, lock-in and security, read custom software vs off-the-shelf software.
Questions to ask before you build
In short: be clear on what changes, who owns it, what it costs in year two, and what the smallest useful version is.
- What exactly will it replace, and what will we keep? Name the tools and spreadsheets that will be retired, and the ones the new system must connect to.
- Which number should move? Hours spent on a report, enquiries without a reply, invoicing errors, days from job completion to invoice. If nobody can name one, the project has no finish line.
- Who owns the process internally? One person who decides how the workflow should run and attends a short demo every week.
- What data has to move, and how clean is it? Migration from old tools and spreadsheets is where timelines slip. Look at the data before you commit.
- What does year two cost? Budget for hosting, typically £15–£250 ($20–$300) a month, and maintenance at around 15–25% of the build cost a year.
- Who will own the code, the data and the cloud account? It should be you, in writing, from the start.
- What is the smallest version worth using? The answer to this becomes your first release.
What to do next: start with one workflow
In short: pick the most expensive workflow, build only that, prove it, then extend.
The custom projects that go wrong usually try to replace everything at once. The ones that work start with one painful workflow and get it into daily use quickly.
Starting small with custom software
- Pick one workflowThe one costing the most time, errors or lost work, not the loudest complaint
- Write it down as it really runsEvery step, spreadsheet and copy-paste, with the person who owns it
- Agree the number that should moveHours saved, errors removed, response time, days to invoice
- Build the smallest useful versionConnected to the tools you keep, reviewed at weekly demos
- Use it daily, measure, then extendThe next workflow is cheaper because the data is already there
Indicatively, an internal tool that replaces a spreadsheet typically costs £1,500–£5,000 ($2,000–$6,000) and a single business module £4,000–£12,000 ($5,000–$15,000). Those ranges are fixed in writing after scoping. The pillar guide to business software for SMEs shows how that first build fits alongside the tools you keep.
DataVolve builds focused custom software for UK and US businesses, usually connected to the accounting, e-mail and payment tools a business already runs. A first working release of a focused tool can be ready in about 10 days, you see progress at weekly demos, and you own the code, cloud account and domain from the first commit. If you have scored 6 or more, tell us about the workflow and we will say honestly whether it is worth building.