Someone spent two sprints perfecting an accordion component. Two sprints of frontend engineering and product design hours. The animations were smooth, bullet-proof accessibility. By any measure, a beautiful accordion.
Meanwhile, the team couldn’t articulate which customer problem they were solving that quarter.
I’ve heard the complaint dozens of times: We can’t ship faster, because of tech debt. It’s been the go-to explanation when velocity disappoints. It’s a safe, technical statement. Nobody gets blamed.
And this is what I’ve learned sitting inside these teams: technical debt is rarely the bottleneck. It’s a cover story for something that is harder to admit.
I was a bridge product architect at a Series A company pushing for Series B. The business complained that the market was outpacing their ability to build. The diagnosis wrote itself: we need to change how we build.
Over two years they scaled the engineering org and migrated a monolith to 23 microservices. I arrived a bit over halfway through.
Domain-driven design, hexagonal architecture, microservices by the book. An architecture to support millions of daily active users. The reality? The business needed a few thousand tops.
To get that clarity, you need to describe your customer accurately. And, you know, that’s a hard task, because it means saying “no” to most of hte pressure to align strategy with everyone’s incentives.
So the easy thing was to point the bottleneck at engineering. Engineering was just slow enough to absorb the confusion without anyone noticing.
The accordion was a symptom of a deeper issue. When you don’t know what to build, you polish what’s in front of you.
The Cover is Gone
Ward Cunningham introduced the technical debt metaphor in 1992. I learned it from him directly, at a workshop at New Relic back in 2014. The framing was clarifying: debt isn’t bad, it’s a financing decision. You borrow against future velocity to ship now. The interest compounds. Eventually, you pay it down or go bankrupt. That made sense when paydown was expensive.
Then AI collapsed the cost of refactoring, migration, test coverage, consolidation: exactly the work that used to justify the debt. The interest rate went to almost zero, which means the excuse is gone. Teams that blamed tech debt for slow delivery are about to discover what was actually slowing them down. The cover story doesn’t work when you can pay off the debt in an afternoon.
On a recent project, we had the choice: use Claude Code to refactor a good portion of the system, or ship what customers needed first. We chose to earn the right to refactor. Ship first, revisit the decision later. The point isn’t that refactoring is free now. The point is that “we have tech debt” stopped being a valid reason to delay. When paydown is cheap, you have to answer the harder question: do you actually know what to build?
The Opportunity
Most teams won’t use this moment to find clarity, they’ll use it to ship faster. More features nobody asked for. More architecture for customers they can’t name. The confusion just deploys quicker now.
Here’s the thing: AI coding assistants just bought you time. The hours you used to spend on refactoring, migration, test coverage… that’s yours again. You can spend it shipping confusion faster or you can spend it answering the question you’ve been avoiding: who is this for, and what do they actually need?
At that Series A company, the fix wasn’t more architecture. It was what Jade Rubick calls a steel thread. The thinnest slice that crosses system boundaries and ships real value. Stop building services in parallel. Earn the next increment by shipping the current one.
"With a Steel Thread approach, you build the thinnest possible version that crosses the boundaries of the system and covers an important use case."
The steel thread forced the question they’d been avoiding: which customer matters most right now?
The teams who win are the ones investing that time in solving more customer problems You’re not slow, you’re confused and now you have the space to fix that.