Product and engineering · Answered by Golden Section from more than 400 B2B software companies observed
Give technical debt and reliability their own swim lane on the roadmap with standing capacity, so the trade-off is made once a quarter in the open rather than every sprint by whoever is under the most pressure. Size the lane by what the debt is costing you now, measured in production defects and slipping sprints. Debt is tolerable when it is documented and isolated; it is not tolerable in the data model, in tenancy, or in security, because those get harder to fix every month customers add data. Almost never rewrite the whole product. Replace it a module at a time behind the running system, and reserve a full rebuild for an architecture that blocks something customers pay for. Start by listing the five places engineers most fear to change, and what each costs per quarter.
Treat debt as a roadmap line with an owner, not a complaint. Pay down first the debt that touches the data model, tenancy, security or release stability, and leave cosmetic debt alone until it costs something measurable.
| Metric | Value | What it means | Source |
|---|---|---|---|
| Production defect fix target | within 48 hours | production defects fixed efficiency, one of the play's sprint metricsa falling rate is one of the clearest signs debt is costing delivery | Golden Section playbookProduct Engineering Process |
| Time for a platform rebuild to show in revenue | about 18 months | from investment to revenue for a structural change such as a platform rebuildthe reason no lender funds a rebuild | Golden Section, publishedGrowth Capital Without Dilution |
Technical debt and features compete for the same engineers, and without a rule the decision gets made sprint by sprint in favor of whatever is loudest. The product management play describes both ditches. A roadmap run by sales ships features on an unreliable product and earns a hostile customer base. A roadmap run by technical founders keeps polishing reliability and stops selling. A reliability lane on the roadmap moves the argument into the quarterly meeting where it belongs.
Not all debt is equal. Debt in the data model compounds, because every customer adds data that will have to be migrated, which is why the database selection play tells you to prioritize debt at the database level and to keep business logic out of the database. Single-tenant architecture compounds the same way. Undocumented code compounds through turnover, since the knowledge leaves with the engineer; code documentation is the cheap insurance. Cosmetic debt, by contrast, can sit for years.
A rewrite feels like the clean answer and is usually the expensive one. It freezes features for a year or more while competitors keep shipping, and the new system relearns the edge cases the old one had already handled.
The numbers are fictional. A company at $4M in annual revenue has seen its successful sprint ratio fall from about 80% to 50% over a year, and production defects now take a week to fix. Engineers propose a full rewrite estimated at fourteen months. The product manager asks them to price the debt instead. Two items explain most of the slippage: business rules written into database procedures, which break with every schema change, and a reporting module with no tests. The company gives the reliability lane a fixed share of each sprint, moves the database logic into the service layer one module per quarter, and adds tests to reporting first. Customers keep receiving features, and the rewrite is shelved.
Where the architecture itself blocks the business, such as single tenancy that makes every new customer a new installation, or a stack that cannot meet a security requirement buyers now demand, a structured rebuild is justified. Fund it as a separate initiative with its own budget and timeline.
From the Golden Section mistakes list, each paired with the play that prevents it.
Logic in the database is the debt that grows fastest, because every schema change has to work around it.
Single tenancy is debt that turns each new customer into another system to maintain.
Not engineering for scale is how today's shortcut becomes next year's rewrite.
Undocumented code makes every repayment slower and leaves with the engineer who wrote it.
In the order we would run them. Each is on its own page, most with a free Excel template.
Puts reliability on the roadmap as its own theme with an owner.
Supplies the sprint and defect metrics that price the debt.
Targets debt at the database level first, where it compounds.
Sets code quality review and modular design so new debt accumulates more slowly.
Keeps knowledge of the code in the repository rather than in people's heads.
Development plays The engineering process, architecture and documentation plays that decide how much debt you carry.
Debt that is documented, isolated and not slowing delivery is acceptable, and every working product carries some. Debt in the data model, tenancy, security or the release process is not, because it grows with every customer you add. The test is cost: if you cannot point to defects, delays or risk it causes, it can wait.
Rarely, and almost never all at once. Rewrite a module when it blocks something customers pay for and incremental change cannot get there, and replace it behind the running product. A full rebuild is justified when the architecture itself blocks the business, and then it should be funded and planned as a structural change, with about eighteen months before it shows in revenue.
The product manager, in the roadmap meeting, with engineering presenting the debt in terms of cost and risk. If engineers decide alone, the product polishes itself and stops selling; if sales decides, reliability erodes until customers notice.
Paying down debt inside the roadmap is an operating job. Rebuilding the platform is different: it takes about eighteen months to show in revenue, no lender funds it, and it is one of the structural changes minority growth equity exists for.
Growth equity →Reviewed by Dougal Cameron, CEO & Co-Founder on 2026-10-22. Golden Section observations are labeled separately from external benchmarks and illustrative arithmetic.