The Undocumented System

The most expensive sentence a founder says is calm, not panicked.

It's not "the system is down" or "we lost data" or "the deployment failed." Those are expensive, but they're visible. They get fixed.

The most expensive sentence is: "It works, but we're a bit nervous to touch it."

What that sentence means

When a founder says they're nervous to touch their own system, they're describing a liability that hasn't sent its invoice yet.

The system runs. Users use it. Revenue comes in. But nobody on the team fully understands how it works. The person who built it has left, or has moved on to other things, or built it in a way that made sense at the time but doesn't document itself.

There's a feature someone wants to add. There's a bug that needs fixing. There's a scaling problem that's coming. And the team looks at the codebase and feels something between uncertainty and dread.

That feeling is the invoice, arriving in instalments.

How systems get undocumented

Systems don't start undocumented. They get that way.

Usually it happens through speed. The first version was built fast, by one person, who understood everything in their head. The system grew. The person left, or got promoted, or got busy. The understanding stayed in their head.

Sometimes it happens through complexity. The system accumulated integrations, workarounds, and edge-case handling until nobody could hold the whole thing in their head at once.

Sometimes it happens through AI. Code written by an AI tool that nobody fully read, deployed because it worked, now running in production with no human who understands it.

The cost

The cost of an undocumented system is measured in three ways.

Velocity. Every change takes longer than it should, because the engineer has to understand the system before they can change it. That understanding has to be rebuilt from scratch every time.

Risk. Every change carries more risk than it should, because the engineer can't see the full dependency graph. They change one thing and break another, because they didn't know the two were connected.

Optionality. The system constrains what you can build next. Features that would be straightforward in a well-understood system become projects. Projects become rewrites.

The fix

The fix is not documentation, exactly. Documentation is a symptom of understanding, not a substitute for it.

The fix is engineering that builds understanding into the system itself. Clear data models. Consistent naming. Tests that describe what the system is supposed to do. Code that reads like it was written for the next engineer, not just for the machine.

This takes longer in the short term. It pays back in every change that follows.

Software that runs but can't change isn't an asset. It's a liability that hasn't sent its invoice yet. We build things you own — that your team can understand, change, and grow.