There's a particular kind of problem that shows up in businesses that have been growing fast. The technology that got them here is starting to limit what they can do next — not dramatically, but in ways that compound.
It usually starts small. A new feature takes longer to build than it should because the data model wasn't designed with it in mind. An integration that should be straightforward requires a workaround because the system wasn't built to talk to anything else. A report that used to run in seconds takes minutes because the database was never optimised for the volume of data it now holds.
Each of these feels like a one-off problem. Together, they're the accumulated interest on an architectural decision that was made early, often under time pressure, and never revisited.
The foundation doesn't have to be wrong to cause this. Sometimes it was entirely the right choice given what the business knew at the time. A database that was perfect for a hundred users a month isn't a failure — it's appropriate to the moment. The problem is when that foundation gets extended and extended without anyone stopping to ask whether it still fits.
What makes this expensive isn't just the eventual cost of fixing it. It's everything that happens in the meantime. Teams working around limitations. Developers reluctant to touch parts of the system they don't fully understand. New features that could differentiate the business not getting built because the underlying system can't support them.
We see it often enough that we now ask about it explicitly in early conversations. Not "do you have technical debt" — everyone does — but "what are the things your current system can't do that you wish it could?" The answers to that question usually tell us more about the state of the foundation than any technical audit.