Most businesses do not decide they need custom software. They notice something is not working, trace it to a tool limitation, try a few workarounds, and eventually reach a point where the workarounds cost more than a real solution would. By then they have usually lived with the problem longer than they realize.
The Spreadsheet Shadow
The clearest sign that a tool is not doing its job is that someone has built a spreadsheet to compensate for it. If you have a CRM and a separate spreadsheet that the team actually uses to track what matters, the CRM is not doing its job. If your scheduling software exists alongside a shared calendar that people maintain manually, the scheduling software is not doing its job.
Shadow systems are not a team behavior problem. They are a tool problem. People create workarounds when the tool does not fit the work, not because they prefer extra steps. I worked with a commercial cleaning company running a separate Google Sheet that six people updated daily to track which crews were assigned to which buildings, because the scheduling tool could not handle recurring multi-location contracts the way the business actually ran them. Nobody built that sheet because they liked extra work.
Manual Steps Between Systems
When information has to be moved from one tool to another by a human, that is a sign of a gap. A lead that comes into your website and gets manually entered into your CRM. A job that gets completed and then manually logged into your billing system. An appointment that gets created in the scheduling tool and then manually added to the project management tool.
Each of these manual transfers is a time cost and an error opportunity. They accumulate. One HVAC company I worked with had two office staff spending a combined four hours per day on data entry between three systems that did not talk to each other. They had normalized it so completely that it was not on anyone’s radar until we put a dollar amount on it.
How to Actually Measure the Cost of Workarounds
The formula is straightforward: (hours per week spent on workarounds) × (fully loaded hourly cost of the employee) × 52 = annual cost of the gap. Run it honestly. Include every person who touches the workaround, not just the person who owns it.
If two people each spend three hours per week on manual data entry between systems, and each person costs the business $30/hr fully loaded, that is 6 hours × $30 × 52 weeks = $9,360 per year. A custom integration that eliminates that process might cost $12,000 to $18,000 to build. The payback period is under two years, and the system keeps running after the payback. That math changes the conversation from "can we afford to build this" to "can we afford not to."
The harder number to measure is the error cost. Missed follow-ups, double-booked jobs, invoices sent with wrong amounts because someone copied data incorrectly. Those do not show up on a timesheet but they show up in churn, in disputes, and in the extra time spent cleaning up mistakes. If you can estimate even one or two incidents per month and what they cost to resolve, add that to the formula.
Your Tool Does Not Know Your Rules
Every business has rules about how it operates. How jobs get priced. Who gets assigned which type of work. What triggers a follow-up and when. What conditions change the workflow.
Off-the-shelf software has its own rules baked in. When your rules do not match, you either change how you operate to match the tool, or you implement the rules manually outside the system. Both options have costs. Changing how you operate to fit the software means losing the operational specifics that differentiate you. Implementing rules manually means more labor and more error.
A concrete example: a specialty contractor whose pricing depends on job type, square footage, ceiling height, and material selection. Off-the-shelf quoting tools give you a generic line-item format. Building a quote in it takes an hour for jobs that should take ten minutes, and the output does not reflect the pricing logic the business developed over years. That is a tool that does not know your rules.
Reporting That Requires Export and Manual Work
If the reports you actually need require exporting data and manipulating it in a spreadsheet, your tool is not fully serving you. This is common and easy to normalize because it feels like the tool is doing most of the work. But if a report takes two hours per week to produce manually that should be a dashboard view, that is real operational cost.
Apply the same hourly formula here. Two hours per week at $35/hr is $3,640 per year for one report. Multiply that across the handful of reports most operations rebuild by hand and a dashboard that surfaces those numbers automatically stops looking like a luxury.
You Have Hit a Feature Limit That the Vendor Will Not Solve
This is a definitive sign. If you have contacted support about a missing feature and been told it is not on the roadmap, or found a workaround suggested in the forums that everyone acknowledges is imperfect, you have reached the edge of what the tool was designed to do. The vendor is building for the average customer, and your need is outside that average.
This is especially common with industry-specific workflows. If your business has anything unusual about how it prices, dispatches, invoices, or follows up, you will eventually find the ceiling of a general-purpose tool.
The Tool Is Limiting What You Can Offer
This is the highest-stakes version of the problem. If the reason you do not offer a service, or the reason your process caps out at a certain volume, is a tool limitation, the software is directly limiting revenue. That changes the ROI math on a custom build significantly.
I have talked to owners who turned down commercial contracts because their scheduling tool could not handle multi-site recurring service agreements. The tool was the bottleneck on growth, not demand. There, the cost of a custom build has to be weighed against the revenue the business is leaving on the table.
When the Signals Are There But Custom Is Still the Wrong Move
Seeing multiple signs does not automatically mean a custom build is the answer. There are a few situations where the right response is something else entirely.
First, the problem might be training, not tooling. If the team is not using the features the tool has, building new software does not fix that. I have seen businesses pay for custom development to replace a tool they were using at 30% of its capability. The new system had the same adoption problems because the underlying issue was not the software.
Second, a no-code or low-code tool might cover it. If the gap is specific enough, something like Airtable with automations, or a properly configured HubSpot, or a purpose-built vertical SaaS might close it without a custom build. I will always surface that option during a discovery engagement if it is there. Building custom software that an existing tool could handle at a fraction of the cost is not something I want to do.
Third, the volume might not justify the investment. A business doing twenty jobs per month has a different math than one doing two hundred. The workaround cost has to actually exceed the build cost plus the ongoing maintenance over a reasonable horizon. If the numbers are close, the simpler option usually wins.
If you want to work through that evaluation in a structured way, the build vs. buy page lays out the framework I use. For a broader look at when the signals actually add up to a justified build, when to build custom software goes deeper on the decision criteria.
What to Do With These Signals
If multiple signals are present and persistent, it is worth doing the evaluation honestly rather than living with the gap another year. At Salterra, I start that evaluation with a discovery engagement. It produces a clear picture of the problem and options for solving it, including whether custom software is actually warranted. The software development page covers how I approach these projects. If you want to understand what the discovery phase looks like specifically, the discovery process page has that detail.