Software needs an owner

Software becomes expensive when nobody clearly owns it. Not when it is old, not when it is written in the wrong language, and not when it was built quickly. Those things make software harder. A missing owner makes it expensive.

What an owner is

An owner is one party who can answer three questions about a system without looking anything up for very long:

1. How does it work, end to end, in production?
2. What is likely to break next, and what happens to users when it does?
3. What would it cost to change it in a specific way?

The owner does not have to be the person who wrote the code. They rarely are. They are the person who is responsible for the system's behavior over time and has the access, knowledge, and authority to act on that responsibility.

An owner is a role, not a permission. Having admin rights on a repository is not ownership. Being the person everyone emails when something breaks is closer, but only if that person can also decide what to fix and when.

How ownership goes missing

We see the same patterns in almost every system we are asked to take over.

The developer left. A freelancer, an early employee, or a small agency built the product and moved on. The code is fine. The knowledge left with them, and nobody was asked to pick it up.

The product was built quickly. A prototype turned into a business faster than anyone planned. Decisions that made sense for a demo are now load-bearing, and nobody remembers which ones.

The product was built with AI. A founder or a small team produced a working application in weeks using AI tools. It works. Nobody on the team can explain why, which is a different problem from it being badly written.

Ownership was split. One vendor runs the infrastructure, another maintains the application, and the customer's own team owns the data. Each party is responsible for their part. Nobody is responsible for the system.

In every case the symptom is the same. Small changes take weeks. Estimates are wide and nervous. Incidents are resolved by restarting things. Every conversation about the software starts with "we would need to look into that."

Why this costs more than it looks

Unowned software does not fail loudly. It fails through friction.

Each change carries an unknown risk, so changes are batched, delayed, or avoided. Features the business needs are quietly dropped. Security updates are postponed because nobody knows what they might break. When a dependency finally forces the issue, the upgrade is large, urgent, and done by someone learning the system under pressure.

The cost shows up as slower product decisions, as staff who route around the software instead of through it, and eventually as a proposal to rewrite the whole thing. Rewrites proposed for this reason are usually a purchase of ownership at the highest available price.

What taking ownership looks like

Ownership starts with understanding, not with changes.

The first weeks are spent reading code, mapping infrastructure, tracing how data moves, and writing down what nobody wrote down. We measure what the system actually does in production, because documentation and reality drift apart. We make a list of what is fragile and what is fine, and we resist the urge to fix things before the list is complete.

Then ownership becomes routine. Dependencies are updated on a schedule. Backups are tested, not assumed. Deployments become boring. Monitoring answers questions before users ask them. Changes have a known cost because someone knows the system.

None of this is glamorous. It is the difference between software that can be changed and software that can only be replaced.

What we are arguing for

Every piece of software that matters to a business should have a named owner who understands it and answers for it. If that owner is inside your organization, protect their time. If nobody fits the description, that is the problem to solve first; taking over an existing system and maintaining it long term is the work AL+ exists for. Everything else, including whether to modernize, rewrite, or leave the system alone, is a decision an owner makes.