Originally published on Ashdown Systems in August 2026, and revised for this blog. Read the original.
Every growing business makes this decision at some point. A problem turns up, there’s no time to think it through, so someone picks the fastest fix available: a new spreadsheet, a free-tier tool, a quick integration someone found on YouTube. It works, and everyone moves on.
Do that ten times over two years and you don’t have ten quick fixes. You have a system. It’s just one that nobody designed, nobody fully understands, and that is now quietly running a large part of the business.
I don’t think this is a story about bad decisions. Most of those individual choices were probably the right call at the time. The problem is that nobody ever goes back and looks at them together.
Why it happens to good teams
Ad-hoc technical debt isn’t a sign of poor management. If anything, it’s a sign of moving fast, which is what growing businesses are supposed to do. Nobody sets out to build a fragile, disconnected set of tools. It happens because:
- Speed beats structure under pressure. When a customer needs something now, “good enough” wins over “correct”. That’s usually the right trade-off. The mistake is never revisiting it.
- The person who made the decision moves on. The automation someone set up last year keeps running long after they’ve left, and nobody knows it exists until it breaks.
- Tools are cheap to add and expensive to remove. Signing up for a new SaaS product takes ten minutes. Untangling it from three other systems a year later takes weeks.
- Nobody owns the whole picture. People own individual tools. Nobody owns how they fit together.
None of that is a failure of judgement. It’s simply what happens by default when there’s no plan.
What it actually costs
The cost rarely arrives as one dramatic event. It shows up as a slow tax on everything the business does.
Time. Somebody is re-keying data that should flow between systems on its own. Multiply that across every week and everyone doing it, and a real slice of payroll goes on work that shouldn’t exist.
Errors. Manual steps and disconnected systems are where mistakes live: the customer billed twice, the order that never reached fulfilment, the report that quietly used last month’s figures because nobody noticed the sync had failed.
Decision quality. When data lives in five places and none of them agree, every decision built on it is on shaky ground. Leaders fall back on gut feel because they don’t trust the numbers, even though the business has the numbers. They just aren’t usable.
Growth capacity. This is the one that bites hardest. A patched-together setup that just about copes at 20 people often doesn’t cope at 50. A minor irritation becomes the thing that stops you scaling, right when scaling matters most.
Hidden risk. Ad-hoc systems tend to hide single points of failure: the one person who understands the invoicing spreadsheet, the integration that will silently stop if a free API tier is withdrawn. You find out they exist when they fail.
The thing I keep coming back to is that these costs compound rather than add up. Each shortcut is cheap on its own. The expense is in what they couple together, so every new fix has to work around all the earlier ones.
The trap of “we’ll fix it later”
The reason this persists is that fixing it never feels urgent, until suddenly it’s very urgent. That’s usually during a growth spurt, a funding round or a busy season: the worst possible time to find out your systems can’t cope.
Waiting for the right moment tends to guarantee the fix happens under the most pressure, with the least time and at the highest cost. Technical debt behaves like financial debt; it accrues interest. Teams that deal with it early pay a small, manageable amount. Teams that wait pay far more, in emergency fixes, lost time and often a painful stretch where the technology simply can’t keep up with demand.
There’s a crossover point where the shortcuts start costing more than doing it properly would have. In my experience, it’s almost always noticed long after it has passed.
It doesn’t mean starting again
The answer is rarely “rip it all out and start over”. For most SMBs that’s neither necessary nor proportionate. What helps is someone stepping back now and then to look at the whole system rather than the individual pieces, and asking a few plain questions:
- Which tools are doing the same job, or working against each other?
- Where is data being copied by hand when it should just flow?
- What is one person away from breaking, with no backup?
- If we grew threefold tomorrow, what would fall over first?
For me, answering those questions properly and building a plan around the answers is what solutions architecture is really for. It isn’t about buying more technology. Often it’s about getting more from what you already have, connected properly, with a clear view of what gets added next and why.
The teams that build this habit early don’t avoid the cost of growth. They pay it steadily, in small amounts, instead of all at once at the worst possible moment.
