According to McKinsey, technical debt accounts for 20 to 40% of a company's entire technology estate value before depreciation. Part of that debt doesn't come from bad code. It comes from an architecture chosen for a growth stage the company outgrew long ago, one that was never reassessed since.
In France, this reality shows up in the daily work of technical teams. According to Stripe's Developer Coefficient study, French developers spend an average of 20.9 hours a week on technical debt, the highest rate among all countries surveyed. That number says nothing about the skill of the teams. It says something about decisions made upstream, often years earlier.
Built for twenty people, running a hundred
A stack chosen for a 20-person team was never built for a team of 100. That's not a flaw in the stack. It's a matter of calibration. The database that handled three thousand active users effortlessly starts slowing down at thirty thousand, not because it's bad, but because it's carrying a load it was never designed to absorb.
Nobody questions that choice at the moment it's made. It's often the right call for the stage the company was at then. The problem shows up later, once the company has changed size several times without ever asking whether the architecture kept up.
How do you know if your tech stack is still fit for purpose? Not by hunting for broken code, but by checking whether features objectively take longer to ship than they did a year ago for a comparable scope. That gradual slowdown, almost invisible week to week, is the most reliable sign that an architecture is still answering to a stage the company has already left behind.
The real cost, in euros and months
According to McKinsey, the CIOs surveyed estimate that technical debt amounts to 20 to 40% of their entire technology estate value, before even counting depreciation. For a Series A company with a 30-person engineering team, that proportion translates into entire weeks of engineering capacity absorbed every year, with no new feature coming out of it.
A Walloon logistics scale-up went through this shift without seeing it coming. The order management system had been built for eight vehicles. Three years later, the company was running sixty on the same technical foundation. A route optimization feature estimated at six weeks took fourteen. The stack had never been bad. It had simply stopped matching the actual scale of the business.
Should you change your stack as the company grows? Not systematically, and rarely in full. The right question isn't whether to rebuild everything, but which parts of the architecture have outgrown their original design and which ones still hold up.
Recalibrate before rebuilding
That's the exact question Nightborn asks before any rebuild project. Not an audit that lists every flaw in the code, but a targeted assessment: which architectural decisions answered to a stage the company has outgrown, and which ones still hold the current load. This work fits into the DevOps approach Nightborn builds with CTOs under pressure, calibrated to one specific project rather than a full rebuild.
The stack never lies about its age. It only lies about whether it still has a reason to be there.
Nightborn supports this recalibration phase through a scoped Team Extension project, designed to adjust the architecture to the company's actual stage without freezing the rest of the roadmap.
.webp)