Most businesses I talk to don’t recognize they’ve outgrown their software because the change is gradual. There’s no single day when a CRM or ERP stops working. Instead there’s a slow accumulation of workarounds, and by the time someone notices, the system has been quietly costing the business for a year or more. This piece lists the concrete, checkable signs — not vague dissatisfaction — that indicate you’ve actually reached that point.
Sign One: One Person Understands the Configuration
If your CRM, ERP, or operations platform has been customized to the point where only one employee (or one outside consultant) fully understands how it’s configured, that’s a structural risk independent of whether the software still "works." What happens if that person leaves? In several projects I’ve scoped, the honest answer was: nobody could safely touch the system, and the business was one resignation away from an operational crisis. That’s not a software problem anymore — it’s a business continuity problem, and it’s a strong sign you’ve outgrown what a general-purpose platform configured by trial and error can safely support.
Sign Two: Your Team Runs Parallel Spreadsheets
When staff maintain spreadsheets alongside the "official" system to track things the software should be tracking, that’s a direct signal the platform isn’t doing its job. I see this constantly with reporting: the CRM can’t produce a report leadership actually needs, so someone exports data weekly and rebuilds it manually in a spreadsheet. That’s not a training issue. It’s a capability gap, and it’s a recurring cost every week it continues.
Sign Three: Integration Requests Keep Getting Declined or Delayed
If you’re regularly asking "can this talk to that system" and the answer keeps coming back as no, or as a workaround involving a third middleware tool, or as a project that never quite gets prioritized by the vendor’s product team, that’s a sign the platform’s native integration ceiling is below what your business actually needs. One or two integration gaps are normal. A pattern of them, especially around core systems like billing or scheduling, is a signal worth taking seriously.
Sign Four: Configuration Changes Now Require a Consultant
Early on, most teams can make small configuration changes themselves. If you’ve reached a point where even minor changes — a new custom field, an adjusted workflow trigger — require hiring outside help because the internal configuration has become too fragile or complex, that’s a sign the system has outgrown what your team can safely maintain. This is often the same moment licensing and consulting costs start climbing together, which is worth running through the TCO framework I lay out in The Real Cost of Software Ownership.
Sign Five: Upgrades Break Things
Heavily customized instances of platforms like Salesforce or HubSpot sometimes break, subtly or badly, when the vendor pushes a platform-level update. If you’ve been burned by this more than once, it’s a sign the customization has exceeded what the platform’s upgrade path was designed to tolerate.
Sign Six: You Can Quantify the Cost, and It’s Not Small
This is the sign that ties the others together. Once you’ve noticed two or three of the signs above, the next step isn’t to build immediately — it’s to quantify what they’re actually costing in staff hours and missed revenue. If that number is small, you likely have a configuration or vendor problem, not a build-vs-buy problem. If it’s large and recurring, the case for a serious look at custom software or a custom layer gets much stronger. I cover the three conditions I look for before recommending a build — including this cost threshold — in Build vs Buy: When Custom Software Is Worth It.
A Seventh Sign Worth Watching: Onboarding Time Is Climbing
One sign that’s easy to miss because it develops slowly is new-employee onboarding time on your core system. If training a new hire on your CRM or operations platform took two days two years ago and takes a week and a half now, that’s usually a direct reflection of how much custom configuration and how many workaround steps have piled up around the base product. Growing onboarding time is a good early proxy for growing system complexity, and it tends to show up before the cost numbers do, because managers notice it in day-to-day frustration long before anyone runs a formal analysis.
How Many Signs Is Enough?
I don’t think there’s a magic threshold, but in practice, one or two of these signs in isolation is usually a configuration or training problem, not a build-vs-buy problem. Three or more, especially when the single-point-of-failure sign and the quantifiable-cost sign both show up together, is when I’d take the question seriously. At that point the right next move isn’t to assume the answer is a custom build — it’s to run the numbers properly, which is why I’d point you to the staged sequence in Buy Then Build: A Staged Strategy for Software Decisions before committing to anything.
What to Do Before You Assume the Answer Is "Build"
Recognizing these signs doesn’t automatically mean custom software is the right next step. Sometimes it means you chose the wrong vendor or the wrong plan tier, and a proper evaluation of alternatives would solve most of the pain for far less money — that process is covered in How to Evaluate Software Vendors. Sometimes it means running the staged approach I describe in Buy Then Build: A Staged Strategy for Software Decisions, so you’re deciding on evidence rather than frustration.
What I’d discourage is ignoring these signs for another year because the current system is "good enough." Good enough with a single point of failure, parallel spreadsheets, and consultant-dependent configuration usually isn’t as good enough as it feels day to day — it’s a slow leak, and slow leaks are expensive by the time anyone adds them up. If you do add them up and the number is real, the fuller framework for deciding what comes next is in Build vs Buy: When Custom Software Is Worth It.