Why internal tools rot, and what stops it

Almost every established company has one: an internal application that works, that nobody fully understands, and that everyone is slightly afraid of.

How it happens

It is rarely bad engineering. It is the absence of ownership.

The tool was built quickly to solve a real problem. It worked, so it grew. The person who wrote it moved on. Nobody was assigned to it because it was not broken. Dependencies aged, the language version fell out of support, and the documentation — never written — stayed unwritten.

Then something needs to change, and the estimate for a small change is three weeks, because the first two are spent understanding what is there.

The warning signs

• Nobody can set up a development copy without help from one specific person
• Deployment involves manual steps in a particular order
• There are no tests, so nobody is confident changing anything
• Dependencies are years behind, several with published vulnerabilities
• The original author is the documentation

What keeps a tool healthy

A named owner. Not a team, a person, with time allocated. The single strongest predictor.

It runs from a fresh checkout. If a new machine can go from repository to running application in under an hour, the knowledge is in the code rather than in someone's head.

Automated dependency updates. Small, frequent, boring. The alternative is a two-year jump that becomes a rewrite.

Enough tests to allow change. Not full coverage — enough that someone unfamiliar can make a change and know they have not broken the invoice calculation.

A written page on why. Not what the code does; why the odd decisions were made. Future maintainers need the reasoning, which the code cannot express.

Reviving one you have inherited

Do not rewrite it. Rewrites of working systems fail more often than they succeed, because the original absorbed years of undocumented business rules.

Instead: get it building reproducibly, add tests around the parts that handle money, update dependencies in small steps, and write the page on why. Six focused weeks usually converts a liability back into an asset.

We take on this kind of work under software development.