Technical debt

Example

A shop runs a three-day promotion. The discount is done quickly: prices are written straight into the code of two pages instead of going through the discount rules. The promotion ends; the code stays. The next promotion takes the same route because it is faster, and within a year pricing rules live in five places.

The interest shows up in hours. A price change that used to take two hours now takes five, because each of those places has to be checked. Four such changes a month is twelve extra hours, and once a year somebody misses a place and the shop sells at the wrong price.

Repayment is usually smaller than it sounds: two days to bring the rules back into one place and cover them with checks. After that a price change takes two hours again. The numbers are illustrative; the ratio is familiar to anyone who has maintained an old site.

Why it matters for a business

Technical debt is invisible on the site and very visible in quotes. When a small change is priced like a large one, the explanation is almost always here. It also explains why some sites are never updated: the team knows an update will break something that is holding the site upright.

It accumulates without anyone making a mistake — an old PHP version, an abandoned plugin, a design drawn before most traffic came from phones. So when we take over an existing project we first estimate how much of it can be changed safely and how much has to be rewritten, whether the work continues on the current site or on our own platform.

What to ask

• Which changes already take longer than they should?
• Are there parts the team avoids touching, and why?
• What versions do PHP, the platform and the add-ons run on, and which are near end of life?
• Is there a staging copy and a set of checks that catch breakage before customers do?
• How much time each month goes to clean-up rather than new features?
• What would it cost to rewrite the part that breaks most often?