Ownership without dependency

There is a fair objection to letting one developer own your system: what if you come to depend on them? What if they leave, raise their rate, or simply become the only person who understands how anything works? It is a real risk, and any honest version of the offer has to answer it rather than wave it away.

The answer starts by naming the alternative honestly. The choice is not between depending on one person and depending on no one. It is between two kinds of dependency.

The dependency you already have

A system that no one owns is not free of dependency. It is dependent on whoever last touched each part — and on the fragments of explanation living in their head, their old chat messages, and the commit they wrote at one in the morning two years ago. Nobody can change it confidently because nobody fully holds it. That is the most expensive dependency there is, and it is the one most small companies already have. It just has no name and no face attached, so it does not feel like a risk until the day a change has to be made and no one can say what it will break.

Researchers who study this call it the bus factor: the number of people who would have to vanish before a system is in serious trouble. On a great many real systems that number is one — and it is one by accident, not by anyone's design. So the question was never whether you will depend on someone. You already do. The question is whether that dependency is being actively reduced, or quietly allowed to grow.

How good ownership lowers it

Taking ownership of a system, done well, is the work of lowering that dependency on purpose — including dependency on the owner. It is not a promise to be trusted; it is a set of concrete things you can point at and check:

• One clear home per rule — so the next person finds where a decision lives by looking, not by asking me.
• Tests anchored to real behaviour — so the next person can change the system and know, without me, whether they broke something.
• Failures that surface on their own — so operating the system does not depend on knowing which log to open.
• Decisions recorded where the code is — so the why behind a structure lives in the system, not only in my memory.

Every one of those makes the system easier for someone else to pick up. It is the opposite of job security through obscurity. The owner's job is to raise the number of people who could safely take over — to push the bus factor up over time, not to be the bus factor.

How you can tell which one you are getting

This is a property you can watch, not a virtue you have to take on faith. A few months in, the test is simple: is the system becoming more legible, or less? Can a developer who is new to it read where things live? Do failures explain themselves? Is the reasoning behind the last significant change written down somewhere you could actually find it?

If those answers trend toward yes, ownership is lowering your dependency, exactly as it should. If the system is instead getting more obscure and more reliant on one person's memory, something is wrong — and that is true whether the person is an outside owner, an overloaded founder, or a full-time hire. The risk was never one person. The risk is unclear systems, and unclear systems trap companies regardless of who happens to be standing next to them.

The honest limit: dependency never reaches zero, and there is always some cost to a handover. A new person still has to learn the business and the system; that time is real, and I will not pretend it away. The claim is narrower and more honest than "no lock-in." It is that a transition stays possible — and that the direction of travel, month over month, is toward a system more people could continue, not fewer.

Why this is built into the offer

I hold myself to this in the open. The values I work by pair each principle with the place in a live system where it can be checked, including where that system is currently falling short — because a standard you cannot verify is just a claim. That same standard is what makes ongoing ownership safe to buy. The goal is not to make you depend on me. It is to leave the system easier for the next serious developer to continue — including, when the time comes, instead of me.