"Move fast and break things" is terrible advice for most companies building software products. But so is "build it perfectly from day one." The truth, as usual, lives in the middle — and most teams never find it.
We've been hired to rescue products where unmanaged debt made every new feature a crisis. We've also watched teams build perfect architecture for products nobody used. Here's the framework we use to avoid both failure modes.
What technical debt actually is
Technical debt is a decision to take a shortcut now in exchange for more work later. The key word is "decision." Accidental complexity from sloppy code isn't technical debt — it's just bad engineering.
Real technical debt is choosing to use a simple database query instead of building a proper search index because you have 500 users, not 50,000. It's using a monolithic architecture because microservices would be premature optimization at your scale.
When debt is the right call
We actively recommend taking on technical debt in specific situations. During MVP development, when you're validating a business hypothesis, optimizing for learning speed over code quality makes sense. You're trying to find out if anyone wants what you're building.
The critical distinction: take on debt intentionally, document it, and have a plan for when to pay it down.
When debt kills products
We've been hired to rescue products where technical debt compounded to the point of paralysis. Common patterns we see: no automated tests (every change risks breaking something), tightly coupled components (can't change one thing without breaking five others), no deployment pipeline (releases are manual, stressful events), and undocumented architecture (only one person understands the system).
The cost isn't just engineering time. It's slow feature development, unreliable systems, difficulty hiring (good engineers don't want to work in a mess), and eventually, the inability to respond to market changes.
Our framework: the three buckets
When we architect a system, every decision goes into one of three buckets. This is the mental model we use on every engagement — and the one we'd recommend you adopt before writing a single line of code.
Non-negotiable foundations
Authentication & security, data model design, CI/CD pipeline, basic testing infrastructure. Getting these wrong early is catastrophically expensive to fix later.
Flexible architecture
API design, service boundaries, caching strategies, search infrastructure. Design interfaces so the implementation can change without breaking consumers.
Acceptable shortcuts
Performance optimization, advanced monitoring, edge case handling. Document what's missing and set concrete trigger conditions for when to address it.
The framework forces clarity: before taking a shortcut, you have to consciously classify it. That classification changes the conversation from "we'll fix it later" to "this is a Bucket 3 item, and we'll address it when X happens."
The paydown plan
Every project we deliver includes a technical debt register — a documented list of shortcuts taken, why they were taken, and the trigger conditions for addressing them. "Refactor the notification system when we exceed 10K daily notifications" is actionable. "Clean up the code someday" is not.
Practical advice
If you're building an early-stage product: invest in foundations (security, data model, deployment) and take intentional shortcuts everywhere else. The word "intentional" is doing all the work there. Document every shortcut. Revisit quarterly.
If you're scaling an existing product and hitting walls: the answer is almost never a complete rewrite. Rewrites take twice as long as estimated, cost twice as much, and often reproduce the original debt in a newer framework. The answer is a targeted refactoring plan — address the highest-impact debt first, keep shipping features, measure the improvement.
The teams that manage debt well don't have less of it. They just always know exactly what they've taken on and when they're going to pay it back.
