पाठशाला Pathshala · उत्पाद Utpād, The product · Lesson 25 · Scale
Technical debt as a financial decision
Debt in a codebase is a loan with an interest rate. Measure the interest in engineer-months and rupees, then schedule paydown against the growth it is blocking.
Pathshala, The Founder Library · 11 October 2026 · 7 min read
Every company past its first hundred customers is carrying technical debt. The question a founder can answer is not whether to have it but what it costs each month and which part of it is worth repaying before the next growth bet.
This lesson treats debt the way a finance head treats a loan: a principal, an interest rate and a repayment schedule. It shows how to measure the interest, how to choose which debt to pay first, a figure to test a paydown plan, and a quarterly review that keeps the decision in rupees rather than in engineers’ moods.
Debt is a loan, so price it like one
The metaphor is older than most startups. Ward Cunningham introduced it in his 1992 experience report on the WyCash system: “Shipping first time code is like going into debt.” The next line is the one founders forget: “Every minute spent on not-quite-right code counts as interest on that debt.” The principal is the work it would take to put the code right. The interest is the time the team loses every week because it has not.
Not all debt is a mistake. Martin Fowler’s technical debt quadrant separates debt that is deliberate or inadvertent from debt that is prudent or reckless. A team that knowingly skips a clean design to make a launch date, and knows what repayment will cost, has taken a prudent loan. A team that ships quick and dirty code because it believes it cannot afford clean code has taken a reckless one. Fowler also notes that prudent inadvertent debt is unavoidable: even an excellent team learns after a year what the design should have been. The financial frame works for all four. Some loans are worth carrying for years, because the interest is low.
Measuring the interest you pay
Interest is time, and time is salary. In Stripe’s Developer Coefficient survey of more than a thousand developers in 2018, the average developer reported spending more than 17 hours of a 41.1-hour week on maintenance: debugging, refactoring and dealing with bad code. CIOs surveyed by McKinsey for Tech debt: Reclaiming tech equity in 2020 said 10 to 20 per cent of the budget meant for new products was diverted to resolving debt. Those are other companies’ numbers. Yours can be measured in a month.
Three measures, used together, give a usable interest rate. Tagged time. Ask engineers to tag each ticket and incident with whether debt caused or slowed it, and sum the hours for a month. The estimate gap. For the next five features, ask for two estimates: as the code stands, and as it would be if the worst module were sound. The difference is interest on that module. Incident cost. Hours spent on incidents traced to known fragile code, plus the customer credits paid for them. Divide total debt hours by total engineering hours. A team of twenty that loses a quarter of its time pays interest equal to five salaries every month.
Which debt to pay first
Debt has a location. The interest on a messy module is roughly how often the team changes it multiplied by how much slower the mess makes each change. A tangled billing module touched every week is expensive. A tangled admin report touched twice a year costs almost nothing, however much it offends the engineer who wrote it. Pull a list of the modules or services changed most often in the last two quarters from version control and put the debt list beside it. The overlap is where the interest is paid.
Then attach each item to the growth it blocks. Debt is easiest to fund when it sits in the path of a bet the company has already made: the enterprise plan that needs role-based access the permissions code cannot support, the second city that needs a multi-warehouse model the inventory tables cannot hold, the Hindi interface that needs strings pulled out of templates. An item that blocks nothing on the [roadmap](/library/roadmap-as-set-of-bets) and costs little interest goes to the bottom, whatever its principal.
At the defaults, twenty engineers at a loaded ₹2 lakh a month losing a quarter of their time, the company pays ₹1.2 crore a year in interest. Left alone, interest drifts up two points a quarter and reaches nearly half of capacity by quarter twelve. Putting a fifth of capacity into paydown costs feature work for the first three quarters, then the plan pulls ahead: by quarter five it has delivered more in total, and over three years it adds about 144 engineer-months of feature work. Lower the return to 0.2, the case where paydown is poorly aimed, and the payback slips past two years. That is the argument for ranking by interest before spending a rupee on principal.
Debt in code that changes every week is expensive. Debt in code nobody touches is free. Pay down the first and leave the second alone.
A worked example: logistics software in Pune
A Pune company sells transport management software to mid-sized shippers. It has 34 engineers at a loaded ₹1.8 lakh a month, and the board has approved a bet on enterprise accounts for the coming year. A month of tagged time shows 28 per cent of engineering hours going to debt. Most of it sits in two places: the rate engine, changed in nearly every sprint and written in a hurry for the first ten customers, and the tenant model, which stores every customer in one set of tables and cannot give an enterprise account its own data boundary.
Interest at 28 per cent of 34 engineers is about 9.5 salaries, or roughly ₹2 crore a year. The team proposes two paydown items. Rebuilding the rate engine is estimated at 18 engineer-months and should cut the estimate gap on rate changes from five days to one, recovering about four engineers’ time; it pays back inside six months. Splitting the tenant model is 30 engineer-months and recovers little time, but the enterprise plan cannot ship without it. The first is funded as an investment with a payback quarter. The second is funded as part of the enterprise bet, and its cost goes into that bet’s budget. A third item, a legacy reporting service everyone dislikes, is touched twice a year and stays where it is.
Scheduling paydown against growth
Two schedules work. A standing allocation, a fixed share of every sprint, suits debt that is spread thin across the codebase and accumulates steadily; 15 to 20 per cent is a common choice and it should be revisited, not inherited. A focused paydown, a team for one or two quarters on one item, suits debt concentrated in a module that blocks a bet. Most companies need both. What fails is the third schedule: none, with a promise to clean up after the next launch.
Avoid the rewrite. A full rewrite replaces known debt with unknown debt and stops feature work for longer than anyone estimates. Replace modules one at a time behind stable interfaces, ship each one, and measure the estimate gap after each. If the interest does not fall, the diagnosis was wrong and the next quarter’s allocation should go elsewhere. Keep the [weekly shipping cadence](/library/shipping-weekly-cadence-that-compounds) running through paydown, because a paydown that ships nothing for three months cannot show its return.
Prevent the reckless kind at the source. Every shortcut taken on purpose to make a date gets a ticket at the time it is taken, with the module, the reason and a rough principal, so the debt list is written by the people who borrowed rather than reconstructed a year later. A borrowing nobody recorded is the most expensive kind, because nobody knows it is there until the interest arrives as an incident.
Putting debt in the board pack
Boards understand loans. Present debt as a single line: interest as a share of engineering capacity, its rupee equivalent, the trend over four quarters, and the paydown items funded with their expected payback. This turns a conversation that usually sounds like engineers asking for permission into one about return on capital. It also protects the team from the opposite mistake. A board that sees interest at 8 per cent and falling will not fund a rewrite because an engineer finds the code untidy.
The quarterly debt review
Once a quarter, in the week before roadmap planning, the engineering lead brings one page. Interest: debt hours as a share of total, from tagged time, with the trend. Hotspots: the ten most changed modules and the debt in each. Paydown results: for every item funded last quarter, the estimate gap before and after. Blocked bets: each roadmap bet and the debt in its path. Proposal: next quarter’s standing allocation and focused items, each with a rupee cost and a payback quarter. The founder decides in the meeting, and the decision is written beside the roadmap so both are read together.
The figure is a simplified model and the Pune company is illustrative. Survey figures are as published by their sources, checked 11 October 2026.
Sources
- Ward Cunningham, The WyCash Portfolio Management System, OOPSLA 1992 experience report — The origin of the debt metaphor, and the interest on not-quite-right code.
- Martin Fowler, Technical Debt Quadrant, 2009 — Deliberate or inadvertent, prudent or reckless.
- Stripe and Harris Poll, The Developer Coefficient, September 2018 — More than 17 hours of a 41.1-hour week on maintenance.
- Vishal Dalal et al., Tech debt: Reclaiming tech equity, McKinsey, October 2020 — 10 to 20 per cent of new-product budget diverted to tech debt.