Why Most Tech Stacks Start Breaking Between £5m and £20m Revenue

If you asked a room full of technology leaders when a growing company's stack starts to strain, most would point to roughly the same band: somewhere between £5m and £20m in revenue. Not because of a single trigger, but because several forces that were harmless at smaller scale all tip over at around the same time.

Why this band specifically

Below £5m, most businesses run on a small, simple stack, one product, one team, one or two environments, and it holds up fine because volume and complexity are both low. Past £20m, most businesses that survived the transition have already rebuilt or re-platformed the parts that needed it, and settled into a more deliberately engineered set-up. The £5m to £20m band is the stretch in between, where volume has grown well past what the original stack was sized for, but the business hasn't yet stopped long enough to rebuild it properly.

What actually breaks first

Data grows faster than the systems built to hold it. A database schema designed for a few thousand records behaves very differently at a few million. Queries that used to return instantly start timing out. Reports that used to run in seconds start running overnight, if they finish at all.

Integrations multiply past what anyone can track. Early on, a handful of third-party tools are wired directly into the product. By £10m or £15m in revenue, that list has usually grown to dozens, added one at a time to solve an immediate problem, with nobody responsible for the integration layer as a whole. Each one is a small risk. Together, they're a fragile web that nobody fully understands.

Deployment goes from occasional to constant, without the tooling catching up. Shipping code twice a month is forgiving of manual processes. Shipping several times a week is not. Businesses in this revenue band are usually releasing far more often than their deployment pipeline, testing coverage and monitoring were ever designed for, and every release becomes a small gamble.

Customer-facing reliability expectations rise faster than the infrastructure does. A handful of early customers will forgive occasional downtime. A book of hundreds of paying customers, several of whom are now large enough to have their own IT and procurement functions, will not. The infrastructure that was adequate for the first cohort is often visibly inadequate for the second, well before anyone has budgeted to replace it.

The people who built the original stack are no longer the people running it. Founders move into different roles, early engineers move on, and the institutional knowledge of why the stack was built the way it was leaves with them. What's left is a system nobody fully understands, being modified by people who didn't design it, under commercial pressure to keep shipping.

Why it feels sudden even though it isn't

Each of these pressures builds gradually, which is exactly why the breakage feels sudden when it arrives. Nobody wakes up one day and decides the stack is now broken. Instead, a slow accumulation of strain crosses a threshold, usually around a product launch, a large new customer, or a funding round that suddenly increases scrutiny, and what used to be manageable becomes visibly, urgently not.

What changes the outcome

The businesses that get through this band without a crisis are usually the ones that started treating architecture and infrastructure as an ongoing investment well before £20m, rather than an emergency rebuild after something breaks publicly. That means someone owning technical debt as a tracked, budgeted line item, someone reviewing the integration and vendor landscape on a regular cadence, and someone senior enough to make the call to slow down and re-platform before the business is forced to.

That's rarely a job a founder or a single senior engineer can do alongside everything else they're carrying. It's a distinct role, and recognising that early is usually cheaper than discovering it the hard way.