Short answer
#The estimate you cannot question
The estimate arrives on a Monday. Moving the product to a new payment provider, six weeks of work, with a paragraph explaining that the old integration is woven through more of the system than anybody expected. The number is higher than you hoped. It may well be right.
That is the uncomfortable part. You have no way of telling. You cannot say which parts of the system the payment integration actually touches, so you cannot say whether six weeks is careful or padded. You could ask another developer, but they would need weeks to find out what the first one already knows, and you would be paying twice for an opinion. So you accept the estimate, not because you agree with it, but because you have nothing to disagree with.
Nobody behaved badly in this story. The developer may be excellent and honest. What it shows is a structure: one person holds the only usable answer to a question about your own system, and every decision that depends on that answer is priced by them.
What this article is about
Not about distrust, and not about replacing anybody. About turning a vague sense of being dependent into something you can list, measure and shorten, while the relationship stays exactly as good as it is.
#It is not about the person
Dependency is usually discussed as if it were a character flaw: the agency that keeps things vague, the developer who will not write anything down. Sometimes that is true. Much more often the dependency was built by perfectly reasonable people doing their jobs well, because doing a job well and leaving behind an explanation of it are different tasks, and only one of them is ever asked for.
A good developer who has worked on a system for three years carries an enormous amount of it in their head. That is precisely why they are good to work with. It is also why their holiday is a risk, why their price has no comparison, and why their departure would cost months. The quality of the person and the size of the dependency grow together.
So the useful question is not whether you trust them. It is where the knowledge, the access and the judgement about your system physically sit, and how many of those places are one person.
#Three lists
Dependency feels like one thing and behaves like three. They have different causes, different costs and a different order in which they can be undone, which is why treating them as one problem usually ends with nothing done about any of them.
Each of the three lists is shortened differently. The dashed box is not dependency at all, and it has to be named separately, or it will be mistaken for something one person is withholding.
-
Knowledge: questions only one person can answer
Where personal data ends up. What runs on a schedule. What breaks if a given external service disappears. Which parts of the system the payment flow touches. Each of these has an answer somewhere, and the list is of the ones where that somewhere is one head.
This is the list behind the estimate you cannot question.
-
Access: accounts only one person holds
The domain registrar, DNS, the cloud account, the code hosting, the app store listings, the payment provider, the service that sends your email. The list is of the ones registered to a personal address, paid for by a personal card or protected by a phone that is not yours.
This list is the most dangerous and the cheapest to fix.
-
Judgement: changes only one person can evaluate
Whether an estimate is reasonable. Whether a proposed change is safe. Whether an incident is serious. The list is of the decisions where, today, the only opinion available is from the person who will also do the work.
This list never goes to zero, and it does not have to.
#Measure in hours, not impressions
Ask an owner how dependent they are and you get an impression: very, somewhat, not really. Impressions do not move, so they cannot tell you whether anything you did helped. A number can, and the simplest one is the time an answer takes when the usual person is not available.
Write down ten questions about your system that a decision in the next quarter will need. For each, record who can answer it, how long it takes without them, and where the answer is written. The table below shows the shape, filled in with invented values.
| Question | Who can answer | Without them | Written where |
|---|---|---|---|
| Which services does customer personal data pass through? | The lead developer | Unknown, probably days | Nowhere |
| What runs on a schedule, and who notices if it stops? | The agency | A morning of reading configuration | Partly, in an old wiki page |
| Who can renew the domain and the certificates? | A former contractor | Not possible | A personal email inbox |
| What does the payment integration touch? | The lead developer | Weeks, for somebody new | Nowhere |
Two columns matter more than the others. “Without them” is your exposure, the time a decision stalls on a holiday, an illness or a falling out. “Written where” is your progress. Every time a cell there changes from nowhere to somewhere checkable, the dependency is shorter by exactly one question, and you can see it.
An owner fills in ten questions for a product built by a small agency. Seven are answered by the same person. Four have no written answer at all. One, the renewal of the domain, cannot be answered by anybody still working on the product. The register did not reveal a bad agency. It revealed that one renewal date could take the whole product offline, and that it would take a single afternoon to fix.
#Access first, because it is cheapest
Of the three lists, access is the one to start with, for two reasons. It carries the worst outcomes, because an account you cannot reach can stop the product entirely and there may be no way back. And it is by far the cheapest to fix, because nothing has to be explained or learned, only transferred.
The rule is simple to state. Every account the product depends on is owned by the company, registered to a company address, paid for by a company card, and protected by recovery methods the company controls. People are members of those accounts with the access their work needs. It is never the other way round.
- Make the inventory. Domain, DNS, certificates, cloud, code hosting, the build and deployment service, app stores, the payment provider, email delivery, analytics, error tracking. For each, write down the owner of record and the recovery path.
- Transfer ownership, keep the people. Move the owner of record to the company and invite the developer back as a member. Their work does not change. What changes is who can still get in the day after they leave.
- Separate the secrets from the accounts. Keys and passwords the system uses live in a place the company controls, not in one laptop. Knowing where they are is not the same as using them, and the owner only needs the first.
This is usually one or two afternoons of work for the developer, done willingly once it is framed correctly. The guide on who owns production infrastructure goes through the list account by account.
#Then move answers out of heads
Knowledge is the list that costs the most to carry and the most to shorten. The traditional answer is to ask for documentation, which fails in a predictable way: writing it is a large task nobody is paid for, it is out of date before it is finished, and the owner cannot tell which parts of it are true.
What works better is to change where an answer comes from, not who writes it. A description of the system built from the system itself, where each claim says what supports it and each gap is named as a gap, can be produced without a person sitting down to write, refreshed when the system changes, and checked by somebody other than its author.
This also changes the role of the person you depend on, in a way most developers welcome. They stop being the only source of answers and become the reviewer of a record. Instead of being interrupted with the same questions every month, they confirm or correct a picture, and their corrections stay in it.
Where 1ADK fits
This is the list 1ADK exists for. The person who has access to the code runs the analysis on their own machine with the coding agent they already use. The result is a picture with evidence under each claim and the unknowns left visible. 1ADK does not require repository access and does not require uploading source code to us. The access and judgement lists are yours to work through with or without it.
#Judgement comes last
Judgement is the list that never empties, and that is fine. You will always rely on somebody skilled to tell you whether a change is safe or an estimate is fair. The problem is not reliance. It is relying on the one person whose interest the answer affects, with nothing to check it against.
Two things shorten this list without turning every decision into an audit.
- A shared picture of what a change touches. When both sides can see which components, integrations and data stores a change involves, an estimate becomes something you can discuss rather than accept. You still do not judge the code. You can ask why the payment change touches the reporting service, and get an answer.
- A second opinion on the few decisions that matter. Not on every ticket. On the irreversible ones: a migration of data, a change of provider, a rewrite. A second opinion is affordable when the second person does not have to rebuild the picture from nothing, which is why this comes after the knowledge list, not before it.
#Raising it without a conflict
Owners often avoid this work because they expect it to sound like an accusation. It does not have to, and the framing decides most of how it goes.
-
Frame it as continuity, not control
The product has to survive anybody being unavailable, including you. That is a reasonable thing for an owner to want, and saying it that way makes it about the product rather than about the person.
Say it out loud: this is insurance, and it covers you as much as it covers me.
-
Ask them to help write the lists
The person you depend on knows better than anybody which questions only they can answer. Asking them to name those questions treats them as the expert they are, and the register gets written in an hour instead of a week.
Most developers have their own list of things they are tired of being the only one to know.
-
Pay for the work
Transferring accounts and reviewing a picture of the system is real work. Put it in the plan with an estimate like any other task, so it is not done grudgingly in the evenings.
Unpaid continuity work is the first thing dropped when a deadline appears.
-
Measure it together
Look at the register again a month later. The number of questions that have a written answer, and the time each takes without the usual person, should both have moved. If they have, say so.
Progress that both sides can see is what keeps this from becoming a one-off clean-up.
#Write the three lists this week
Access
Any item owned by a person rather than the company goes to the top of the plan.
- Who is the owner of record of the domain, and where does the renewal notice go? A lapsed domain takes everything offline at once, and the recovery can take weeks.
- Whose card pays for the cloud account, and who can reset its password? The account that hosts the product is the one that must never be personal.
- Who can grant access to the code hosting if the current admin disappears? Losing it does not delete the code, but it can stop every deployment.
Knowledge
Each question without a written answer is one line in the register.
- Write ten questions a decision next quarter will need, and who answers each. The list of questions is more useful than any answer, because it shows where the answers are missing.
- Mark the ones whose answer is written somewhere you could check. That count is your starting point, and it is usually lower than expected.
Judgement
Only the decisions that cannot be undone.
- Name the next irreversible technical decision on the plan. That is where a second opinion pays for itself.
- Say whether anybody other than the person doing the work could assess it today. If not, the knowledge list is the thing to work on first.
#What people do instead
Ask for complete documentation of the system.
Instead Complete documentation is never finished and never checked. Ask for the ten questions in the register to have written answers that can be verified, and grow the list from there.
Hire a second developer to learn everything the first one knows.
Instead This doubles the cost and creates a second dependency on a slower clock. Shorten the knowledge list first, so whoever arrives next starts from a record rather than from a person.
Collect every password in one tense evening.
Instead A list of passwords is not ownership, and it leaves the accounts registered to the same person. Transfer the owner of record of each account, calmly, and keep the people as members.
Change agency to escape the dependency.
Instead A new agency inherits the same structure and starts by charging for learning what the old one knew. Change suppliers for other reasons, and only after the three lists are short.
Treat the unknowns as something the developer is hiding.
Instead Some things nobody knows, including the person who built the system. Name them as unknowns in the record. Accusing somebody of withholding what they never had ends the cooperation you need.
#What this does not fix
Shortening the three lists makes dependency a choice rather than a trap. Plainly, what it does not do.
What this does not do
- It does not remove the need for skilled people. You will still depend on somebody to build and change the system, and that is healthy when it is a choice.
- It does not tell you whether a person is doing good work. A record of the system says what exists and what is connected, not how well it was made.
- It does not capture decisions that were never in the system. Why a price was set or a feature was dropped lives with the people who decided, and has to be written down by them.
- It does not make an estimate correct. It makes it discussable, which is a different and smaller thing.
- It does not finish. Systems change and people join and leave, so the register is kept, not completed.
The goal is not independence from people. It is that no single person is the only way to answer a question about your own product, to get into an account it runs on, or to judge a change you are about to pay for.
If the person you depend on most were unreachable for a month starting tomorrow, which of your three lists would stop the business first?