Technical debt

The work that quietly did not happen.

Every environment carries a backlog of maintenance nobody got to. It does not announce itself, it compounds, and it surfaces at the worst possible moment. It gets cleared on a plan and then kept clear, which is what a flat monthly fee pays for.

The idea

Every shortcut is borrowed against a later day.

Something breaks on a Friday. Somebody fixes it, and the fix works. The cleanup, the documentation, the proper version of that fix, all of it gets scheduled for a quieter week that never arrives. The shortcut stays in the environment and starts earning interest.

Do that for ten years, across a dozen people, some of whom have since left, and you get the environment most businesses actually run on. Nothing in it was careless. Every single decision made sense on the day it was made. The debt is what accumulated in between.

The awkward part is that debt is quiet right up until it is not. An environment carrying a decade of it looks identical, from the outside, to one carrying none. Both of them boot. Both of them serve files. The difference only shows up on the day something goes wrong, and by then the whole bill arrives at once.

In practice

You have probably met several of these.

None of this is exotic. It is the ordinary residue of a working environment, and it turns up in every layer of one. Security is in here, and so are storage, directory, documentation, and hardware that is quietly aging out.

Network

The rule nobody remembers adding

An allow rule from a project that ended years ago, still open, still doing something. Nobody removes it because nobody can say for certain what stops working if they do.

Backups

The job that has never been restored from

Green every night for four years. Until somebody restores from it you have a job that reports success, and the day you need it is a poor time to learn the difference.

Servers

Past the last patch it will ever get

A machine running an operating system that stopped receiving fixes. It works perfectly, which is why it is still there and why nobody has costed the replacement.

Directory

The box everyone routes around

The server with the informal warning attached to it. Changes get designed around it, which quietly shapes every decision that follows.

Access

The account nobody disabled

Someone left in 2021 and their login still works. Or three people share one admin password because that was faster on the day it was set up. Neither gets noticed until somebody goes looking, and the looking usually starts after something has already gone wrong.

Documentation

A network with no current map

Built by somebody who has moved on. Every change starts with archaeology, and the person doing the digging is charging you for the hour either way.

Storage

Ninety percent full, no growth plan

Capacity that has climbed steadily for two years with nothing modelling where it lands next quarter. Storage problems announce themselves late and then all at once.

Lifecycle

Renewals with nobody's name on them

Certificates, licences, and support contracts that expire on a date no calendar holds. These fail cleanly and completely, usually outside business hours.

Recovery

Untested since the last outage

Startup order that has drifted as things were added. Which machines come back by themselves after a power cut, and in what order, is worth knowing before the next one.

The approach

Clear it on a schedule, then keep it clear.

The baseline carries an order, a timeline, and a cost against each item, so you can see the end of the work from the start of it.

Remediation is quoted flat, in writing, before anything is touched. Some of it your own people may well close themselves, and where that is true I will say so. What is left gets scheduled and finished.

The monthly work is what stops a new backlog forming. Debt accumulates because maintenance is the thing that gets postponed when something louder turns up. Patching, backup verification, firewall and directory review, documentation kept current: all of it slips. Putting it on a schedule somebody else owns is the whole point of the retainer.

Where to start

Counting it is the first thing I do.

Every engagement opens the same way. I document what is actually there: what you run, what condition it is in, what is carrying risk, and what I would fix in what order. That is the baseline. It carries a flat fee, and that fee comes off your first invoice if you go ahead within 90 days.

Most of what it finds will not surprise you. The value is seeing the whole list in one place, ordered, instead of carrying it around as a vague sense that some things probably need attention.

The counting is the easy part. A list of problems handed over at the door is worth very little on its own. What you are paying for is somebody working through it on a schedule and telling you what moved. That is the retainer, and the baseline is where it starts.

Here is a full example of a baseline, written for a fictional company, so you can see exactly what the first month produces.

The baseline carries a flat fee that credits back against your first invoice if you go ahead, and any remediation it turns up is quoted flat, in writing, before anything is touched. Retainers are published by environment size with no hourly rate anywhere. The full pricing is on the main page.

Start with a written note