The software rarely breaks first. People work around it first.
That’s what makes this hard to catch. A system that’s been outgrown doesn’t crash, and it doesn’t show up on any monitoring dashboard. It carries on doing exactly what it was built to do. Meanwhile the company assembles a second, informal system around it, out of spreadsheets, group chats and people who remember things.
By the time anyone says the word “replace”, that’s usually been running for a year.
So the signals worth watching aren’t technical. You don’t need to read the code to find them. You need to watch what your staff do when the system gets in their way.
The workarounds tell you first
A workaround is an unmet requirement, written in the only language available to the person who hit it.
Look for the places where data leaves the system and comes back. Someone exports to a spreadsheet, does the real work there, and types the result back in. That round trip is a feature request. So is the shared mailbox tracking what the system won’t, the group chat where the actual scheduling happens, the printed sheet stuck to the wall by the despatch bench.
None of this means your team is undisciplined. It means the opposite. Competent people route around obstacles quietly, and they’ll keep doing it for years without escalating, because the workaround works. The obstacle is the part worth your attention.
So count workarounds, not bugs. A system with almost no bugs and a dozen workarounds has been outgrown.
The business has started shaping itself around the software
This is the one that settles the question.
Watch how decisions get made. Has anyone turned down a piece of work because the system can’t invoice it that way? Priced something oddly because that’s the only structure the pricing screen allows? Kept a process that stopped making sense, because changing it would mean changing the software?
Software is meant to absorb how the business works. When the direction reverses, and the business starts absorbing how the software works, you’ve outgrown it. Everything else here is a symptom. This one is the definition.
It’s also the expensive one, because it never appears in your costs. It appears in the work you didn’t take.
Small changes stopped being small
Ask what your last four change requests cost, and put them in order.
You’re looking for a trend, not a number. If “add a field to that form” used to take two days and now takes two weeks, the code is telling you something through the invoice. Each new feature is being threaded through more existing behaviour than the last one, and the next one will cost more again.
A developer will call this technical debt. From your chair it’s simpler: the system is getting harder to change, so you change it less, so it falls further behind what the business needs. That loop tightens on its own.
Nobody can say what it does
Ask two people who use the system daily to explain one rule it enforces. How a discount is calculated, when an order gets flagged, why a record can’t be deleted after a certain point. If you get two different answers, or two versions of “it just does that”, those rules exist only in the code.
That’s survivable while whoever wrote the code is still reachable. Often they aren’t. The developer left, the agency wound down, the contract ended years ago. What’s left is software nobody can describe and nobody wants to touch, where any change starts with weeks of reading before a line gets written.
The clearest version of this is a new hire who takes months to become useful, because someone has to sit with them and explain the tricks. The system needs teaching rather than using.
Growing pains are not the same thing
Not every complaint means the software has run out of road. Treating them all the same way is how companies end up rebuilding something that was fine.
The distinction that holds up: does the system do its job badly, or has its job changed?
Slow screens, a dated interface, a clumsy workflow, a missing report. Those are defects and gaps. They’re fixable inside the current design, usually cheaply, and a rebuild is an expensive way to solve them.
Outgrown is different. The system models a company you no longer are. It assumes one site and you have four. It assumes one currency, one legal entity, one way of pricing. It has no concept of a thing you now sell every day. A better screen won’t fix that, because the shape underneath is wrong.
If the answer to “what would fix this” is a list of changes, you have growing pains. If it’s a sentence that starts “well, the whole thing assumes…”, you’ve outgrown it.
What this doesn’t mean
Recognising three of these doesn’t mean you need a rebuild, and anyone who tells you it does hasn’t looked yet.
The usual picture is narrower. One part of the system is carrying the strain and the rest is fine. Often the fix is to move that one capability out, leave everything else where it is, and stop the daily bleeding without a project that swallows a year. Sometimes the right answer is to do nothing yet, and write down what would have to change for that to stop being true.
What doesn’t work is the option most companies take by default, which is waiting until the system actually breaks. By then you’re choosing under pressure, on someone else’s timetable, and every option is worse than the ones you had back when the only symptom was a spreadsheet on somebody’s desktop.
If you recognise more than a couple of these, the useful next step isn’t a quote. It’s working out which part is actually under strain, and whether you’re looking at growing pains or a shape problem. Tell us what’s happening at get a proposal and you’ll have a written proposal within 48 hours.