Technical Debt: When to Pay It Down and When to Ship

Ship with technical debt when you are still testing whether people want the product and the shortcut is easy to undo. Pay it down when it slows every change, touches money or customer data, or will break as you grow. Keep a written list of your debt and set aside a fixed share of each work cycle to repay it.

I co-founded Hackhouse, a builders' hub in Nairobi, and "do we rewrite this or ship it?" is one of the most common questions early teams face. This guide gives you a way to answer it for each shortcut, with signals to watch and a routine that fits a team of two to ten engineers.

What is technical debt?

Ward Cunningham coined the metaphor in his 1992 OOPSLA experience report on the WyCash portfolio system. He wrote that "shipping first time code is like going into debt" and that "every minute spent on not-quite-right code counts as interest on that debt" (Cunningham, 1992).

Martin Fowler later split debt into four kinds along two lines: deliberate or inadvertent, and prudent or reckless (Fowler, 2009). Prudent, deliberate debt is a choice you make with your eyes open, such as cutting a corner to hit a launch date with a plan to fix it. Reckless debt is the kind a team piles up without noticing, or by skipping care it knows it needs.

The aim is to take on the prudent kind on purpose and limit the reckless kind.

Why does technical debt matter for a startup?

Debt charges interest on every future change. In Stack Overflow's 2024 Developer Survey, "amount of technical debt" was the top frustration at work, chosen by 62.4% of respondents (Stack Overflow, 2024).

For a startup, the cost shows up as slower releases, more bugs after each deploy and engineers who are afraid to touch parts of the code. DORA, the research programme on software delivery, tracks this with five metrics, including change lead time (how long a change takes to reach production) and change fail rate (the share of deployments that need immediate intervention) (DORA, updated January 2026). If those numbers get worse month after month, debt is a likely cause.

When should a startup ship and take on debt?

Take the shortcut when most of these are true:

• You are testing demand, and you do not yet know whether anyone will use the feature.
• The change is easy to reverse or delete.
• A bug would affect few users and no money or personal data.
• Shipping this week teaches you something a planning meeting cannot.
• You can write down the shortcut and a date to revisit it.

For example, a rough onboarding screen that reaches users this week returns data you can act on. A polished one that ships next quarter returns nothing until then.

When should you pay technical debt down?

Repay debt first when it sits in one of these places:

• Money. Payment flows need to handle retries and duplicate callbacks without charging a customer twice. If you take M-Pesa or card payments, fix shortcuts here before anything else.
• Security and personal data. Hard-coded keys, missing access checks and unencrypted customer data are debt with legal and trust costs.
• Code everyone has to touch. If most changes pass through one tangled module, every feature pays its interest.
• Knowledge held by one person. If only your founding engineer understands a system, it stops whenever they are away.
• Assumptions that block growth. One currency, one country or one phone number format hard-coded across the app will break when you expand.
• Performance on cheap phones. Heavy pages and slow queries that were fine for a hundred users can fail for thousands on entry-level Android phones and weak connections.

The signal to switch is when your main question moves from "does anyone want this?" to "can we serve everyone who does?"

How do small teams manage technical debt?

1. Keep a debt register. A shared document or a label in your issue tracker. For each item, note what the shortcut is, why you took it, what it costs you now and a date to review it.
2. Name debt when you take it. Say it in the pull request: "We are skipping tests on this flow to hit Friday's demo, and we will add them next sprint."
3. Reserve time every cycle. Set aside a fixed share of each sprint, for example one day in ten, for repayment. Protect it the way you protect a customer deadline.
4. Pay down debt where you are already working. When a feature touches a messy module, clean that module as part of the work.
5. Track two DORA metrics monthly. Change lead time and change fail rate are enough to show whether things are improving.
6. Rewrite only with a reason. A full rewrite stops feature work for weeks. Do it only when you can name what it unblocks, and prefer replacing one part at a time.

A reliable deploy pipeline makes repayment cheaper, because small fixes can ship safely every day. Our guide to DevOps for small teams covers the setup.

What questions should I ask about any shortcut?

• What will this cost us each week if we leave it?
• Can we undo it easily if we are wrong?
• Does it touch money, security or personal data?
• Could a new hire understand it from the code and the notes?
• When will we look at it again, and who owns that?

If you want to compare notes with other teams making the same calls, our communities and events bring builders together in Nairobi, and the Hackhouse Residency is a 12-week programme for founders that takes no equity.

Key facts

• Ward Cunningham introduced the technical debt metaphor in a 1992 OOPSLA experience report.
• Martin Fowler's quadrant splits debt into deliberate or inadvertent, and prudent or reckless.
• Technical debt was the top workplace frustration in Stack Overflow's 2024 survey, at 62.4%.
• DORA tracks five software delivery metrics, including change lead time and change fail rate.
• Debt in payments, security and personal data should be repaid first.

Frequently asked questions

Is technical debt always bad?

No. Deliberate, prudent debt helps you reach users sooner and learn faster. It becomes a problem when nobody tracks it and the interest starts slowing every change.

How much time should we spend paying down technical debt?

There is no fixed rule. Many teams reserve a set share of each sprint, such as one day in ten, and increase it when their DORA metrics get worse.

Should we rewrite our app from scratch?

Rarely. Replace the worst parts one at a time while you keep shipping. Consider a full rewrite only when you can name what it unblocks and the business can pause features for the time it takes.

How do I explain technical debt to a non-technical co-founder?

Use Cunningham's loan comparison. Each shortcut borrows time now and charges interest later in slower releases and more bugs. Show the debt register and the DORA numbers so the trade-off is visible.

Sources

• The WyCash Portfolio Management System, Ward Cunningham, OOPSLA 1992, checked 5 Nov 2026
• Technical Debt Quadrant, Martin Fowler, checked 5 Nov 2026
• 2024 Developer Survey: Professional Developers, Stack Overflow, checked 5 Nov 2026
• DORA's software delivery performance metrics, DORA, checked 5 Nov 2026

Go deeper with us. Join the Hackhouse community for conversations that go beyond the surface, where builders share the hard-won lessons that never make it into press releases.