Building the Product

We ship fast but our codebase is turning into a mess. How much should a two-person startup care about tech debt?

A starting point

Some tech debt is the correct price of learning fast, and paying it all down early is a way to avoid talking to users. As a starting point: take on debt freely in code that might get deleted next month, but keep the parts you touch every week (auth, payments, core data model) clean, because slow changes there quietly kill your shipping speed. The tell that debt has gone too far is when a small change starts taking three days and you stop shipping weekly at all.

Go deeper

Hand-picked from around the web, each with a note on why it earns your time.

2 resources 2 link-checked Watch Read

Watch

▶️ Video

✓ Link checked Free Intermediate

Why we picked it The honest answer to "how much should we care" is: care about the mess that is actually in your way, and ignore the rest. Tornhill makes this concrete. Most of a codebase is code you rarely touch, so its messiness costs you almost nothing. The debt worth paying down lives in the few files you keep editing. For a two-person team with no time to spare, that is the whole game: fix the hotspots you keep tripping over, leave the quiet corners alone.

Prioritizing Technical Debt as if Time and Money Matters

On GOTO Conferences (YouTube) by Adam Tornhill About 40 minutes

A messy file you never touch is not really costing you. Prioritize debt by where your code actually changes most, not by where it looks worst.
Trying to clean up everything is a trap for a small team. Target the overlap of complex and frequently changed code, that is where cleanup pays for itself.
Framing tech debt in terms of the time and money it costs you makes it a business decision you can defend, not a purity project.

Watch on YouTube youtube.com →

Read

✍️ Essay

✓ Link checked Free Beginner

Why we picked it This is the canonical framing for exactly your question: not all messy code is the same. Fowler splits debt on two axes, whether you took it on deliberately or by accident, and whether the call was prudent or reckless. For a two-person team shipping fast, the useful cell is deliberate and prudent: you know you cut a corner, you thought about the payoff, and you plan to come back. That is a healthy place to be, and this piece gives you the language to tell it apart from the reckless kind that actually hurts.

Technical Debt Quadrant

From martinfowler.com by Martin Fowler About a 5 minute read

Debt taken on deliberately and prudently (a conscious shortcut with a payoff in mind) is fine, and often smart, when you are racing to ship.
The debt to fear is the reckless kind: messy code from not knowing better, or knowingly cutting corners you cannot afford. That is the interest that compounds.
Some debt is inadvertent and prudent, you only learn the right design after building it. That is unavoidable and not a failure, so do not beat yourselves up over it.

Open martinfowler.com →

People also ask

How do I decide what to build next? Prioritize outcomes, not output, and use a simple scoring frame like RICE, Reach x Impact x Confidence, divided by Effort, to compare ideas honestl... Intermediate 2 resources → How often should an early-stage startup ship? Ship weekly, at least, cadence is a competitive advantage because faster loops mean faster learning. You haven't really started until you launch, a... Beginner 2 resources → How do I build a roadmap without over-planning? Work in short fixed cycles with variable scope, Basecamp's Shape Up runs on six-week bets, not a rigid multi-quarter Gantt chart. Make a few bets y... Intermediate 2 resources → How do I keep talking to users while I'm heads-down building? Make discovery continuous, not a one-time phase: interview a customer or two every single week, even in a build sprint. Teresa Torres's opportunity... Intermediate 2 resources → How do product teams keep a consistent shipping rhythm as they grow? Separate your planning cadence from your execution cadence and lean on async updates instead of endless meetings. A predictable operating rhythm, w... Advanced 2 resources → How do I say no to feature requests without losing customers? Anchor every 'no' to the outcome you're chasing and the customers you're building for, most requests are solutions in disguise, so dig for the unde... Intermediate 3 resources →