Technical Debt: When to Pay It Down and When to Ship
Photo by Unsplash
I have watched the same scene play out in a dozen Nairobi co-working spaces.
A founder pulls me aside, laptop half open, and asks the question that keeps engineers awake.
"Do we rewrite this, or do we just ship?"
The honest answer is that both choices can be right, and both can sink you. The skill is knowing which is which on a given Tuesday, with the runway you actually have. So let me give you the way I think about it, built for how we build on this continent.
The debt is a loan, and that is good news
Ward Cunningham gave us this metaphor back in 1992, at the OOPSLA conference, when he had to explain to his boss why a shipped financial application would still need a rewrite (Cunningham, 1992). His framing has held up because it is precise.
Shipping code you do not fully trust is like taking a loan. A small, deliberate loan lets you move faster than your competitors, reach the market, and learn from real users. The trouble starts when you forget you borrowed, and the interest quietly eats your velocity.
That word, interest, is the whole game. Every messy module, every copy-pasted function, every "we will clean this later" charges you a little tax on every future change. The JetBrains 2025 developer survey found engineers losing two to five working days a month to that tax (JetBrains, 2025). The 2024 Stack Overflow survey ranked technical debt the single biggest day-to-day frustration for 63% of professional developers (Stack Overflow, 2024).
Debt is a tool. Like any loan, the real question is whether you can afford the repayments.
Ship when learning is the bottleneck
Early on, the most expensive thing you can do is build the wrong product beautifully.
If you do not yet know whether anyone wants the thing, clean architecture is a cost with no return. You are paying for flexibility you may never use. This is the moment to ship, deliberately and a little roughly, and let the market tell you the truth.
Take the loan when the feature is reversible, when the blast radius of a bug is small, when you are testing demand rather than scaling it, and when speed to a real user teaches you something you cannot learn in a planning meeting. A rough onboarding flow that ships this week beats a perfect one that ships next quarter, because the rough one returns data.
The founders who get this wrong tend to be strong engineers polishing an engine for a car nobody has agreed to buy.
Pay it down when the debt starts charging interest on growth
The signal flips the day your problem stops being "does anyone want this" and becomes "can we serve everyone who does."
This is where African builders carry a specific weight. Most of our users reach us on phones. Mobile accounts for roughly 74 to 75% of web traffic across the continent (Statista, January 2024), and in many measured markets 40 to 60% of users are effectively mobile-only, often on intermittent connections (GSMA, 2024). That context turns certain shortcuts from cheap into dangerous. A bloated payload or a brittle offline state is a minor sin in San Francisco and a churn machine in Kisumu or Kano.
So pay down the debt that compounds with scale. The slow query that was invisible at a thousand users will page your team at a hundred thousand. The payment edge case you skipped becomes a support fire and a trust problem the moment money is at stake. The hardcoded assumption about one country breaks the week you expand to the next.
You can watch this discipline at work in companies still standing after a brutal funding winter. Flutterwave (Nigeria) spent 2025 and early 2026 rebuilding its core into proper financial infrastructure, acquiring the open-banking startup Mono and securing a banking license to support a vertically integrated stack (Businessday, 2026). That is a company choosing to repay foundational debt precisely because it intends to scale on top of it.
Make the trade-off out loud
The most damaging technical debt is the kind nobody decided to take.
Healthy teams borrow on purpose. They say, in the open, "we are skipping the automated tests on this flow to hit the demo, and we will add them in the sprint after." The debt is named, written down, and given a repayment date. Unhealthy teams accumulate the same shortcuts by accident and discover the balance only when the system buckles.
A practical rhythm I recommend to Startinev founders: keep a short, visible debt list, and ring-fence a slice of every cycle, even 15 to 20%, for repayment. The Protiviti 2025 survey found organisations already losing about 30% of their IT budgets to unmanaged debt (Protiviti, 2025). You will pay either way. Paying on a schedule you chose is far cheaper than paying when the system chooses for you.
The African constraint that changes the math
There is one more factor we cannot copy-paste from foreign playbooks: people.
Africa has a large and fast-growing engineering base, roughly 716,000 professional developers as of the Google and Accenture report in 2021 (Google/Accenture, 2021), with the pool growing around 21% a year since (Develop the Developers, 2024). Senior engineers remain scarce, a point Moniepoint CEO Tosin Eniolorunda made sharply in May 2026 when he said the continent is short on senior talent (Businessday, 2026).
That scarcity should shape how you borrow. Debt that only your founding engineer can navigate is a single point of failure walking around with a laptop. When your team is junior-heavy, clarity becomes an asset worth paying for early, because readable code is how you onboard the next five hires without burning the first one out.
The one question to carry
Strip away the frameworks and it comes down to this. Ask of any shortcut: what does the interest cost, and can I pay it before it compounds?
Ship when the loan buys you learning you cannot get otherwise. Pay it down when the interest starts taxing your ability to grow, serve users on real African networks, or keep your team sane. Borrow on purpose, write it down, and repay on a schedule you set.
Build boldly. Borrow wisely. And never let the interest run the company.
