Short answer
#The five dimensions
| Dimension | The question | A bad answer |
|---|---|---|
| Ownership | Whose name is each account in? | "It's on their AWS organisation." |
| Operability | Could anybody else deploy this tomorrow? | "They have a process for it." |
| Understanding | Can anybody outside the supplier describe the system? | "They know it inside out." |
| Credentials | Who holds the keys, and where are they? | "In their password manager." |
| Replaceability | How long from decision to a new team shipping? | "We've never thought about it." |
Note what all the bad answers have in common: none of them is a complaint about the supplier. Each describes a perfectly normal arrangement that quietly transfers a company's optionality to somebody else.
#Ownership: the one that can strand you
Every other dimension costs you time and money. This one can cost you the ability to operate.
Work through this list and, for each, establish whether the owning identity is an account your company controls — not whether you have access to it.
The ones that can stop your product
If any of these is in the supplier's name, fix it before anything else on this page.
- The domain registration Loss of the domain is loss of the product, the email and every integration that resolves to it.
- DNS
- The cloud account or organisation A sub-account inside a supplier's organisation is not yours, however much access you have.
- The production database, and its backups
- TLS certificates and anything that renews automatically
The ones that cost money and time
- The source repository and its history
- CI/CD, and the secrets stored inside it
- The payment provider account
- Email and transactional messaging
- Error tracking, monitoring, analytics
- App store publisher accounts, if there is a mobile product
The ones people forget
- Recovery email and phone number on every account above A company-owned account whose recovery address is a personal mailbox is not company-owned.
- The billing relationship — who receives the invoice from each provider
- Any account created with a personal address “just to get started”
Who should own production infrastructure goes through the correct arrangement and how to move to it without a fight.
#Understanding: the expensive one
This is the dimension that decides how long and how painful a change of supplier is, and it is the one nobody measures.
Understanding of the system is an asset, and if the only copy of it lives inside a supplier, then your position is: you can change supplier at any time, and doing so costs several months of a new team rediscovering what the old one already knew — paid for by you, twice.
This is what makes vendor dependency different from ordinary supplier risk. You can switch cleaning companies on a month's notice. You cannot switch development suppliers on a month's notice unless somebody has already made the understanding transferable.
The practical test: can anybody outside the supplier describe what the system is made of, what it depends on, and what happens when a payment fails? If the honest answer is no, the understanding dimension is at maximum regardless of how good the contract is.
#Signals worth noticing
None of these proves bad faith. All of them are worth a question.
- Estimates for small changes that keep coming in higher than they sound.
- Reluctance to let anybody else look at the system — "it would take longer to explain than to do".
- Documentation that never quite arrives, over years.
- All communication going through one person on their side.
- Access to production available only via their tooling or their VPN.
- New accounts still being created in their name today.
- An answer to "how would we move this?" that starts with "you wouldn't want to".
A fair reading
Most of these have innocent explanations, and a supplier under commercial pressure has genuine reasons for several of them. The point is not to diagnose motive. It is that each one describes a state of affairs that is worse for you than the alternative, whatever caused it.
#Reducing it without changing supplier
Almost everything here is compatible with keeping a supplier you are happy with — which is usually the right outcome.
-
Move ownership of every account to company identities
This is the highest-value afternoon available to you. It changes nothing about how the supplier works and removes the worst category of exposure entirely.
-
Get a technical picture that does not come from them
Derived from the system, with citations. Not as a challenge — as a company asset that would survive any change of supplier, including one they initiate.
-
Have somebody outside deploy, once
A single supervised release by anyone who is not them converts “they have a process” into a fact.
-
Restore a backup into a scratch environment
Same reasoning. This is the test that most often fails, and much better discovered now.
-
Write the transition into the contract
Not as a threat: as a normal clause. Accounts remain company-owned; on termination, a defined handover period with defined acceptance tests. Both sides benefit from it existing before it is needed.
-
Analyse the system periodically
A picture refreshed a few times a year is what makes a supplier change a project rather than an excavation.
#Lock-in that is nobody's fault
Some dependency is structural rather than relational, and it is worth separating from the rest so it can be managed instead of resented.
- Platform choices. A system built entirely on one cloud's managed services is harder to move, and that may have been the correct trade.
- Proprietary components. A supplier's own framework or internal library inside your product is a dependency on them that outlives the contract.
- Unusual technology. A stack few people know is a small hiring market, whoever the supplier is.
- Undocumented conventions. A system with strong internal patterns nobody has written down is expensive for any newcomer.
Vendor lock-in in software development deals with which of these are worth paying to avoid and which are not.
#Where 1ADK helps, and where it does not
Where it helps
- A technical picture the company owns, independent of the supplier.
- The integrations map, which is where undeclared dependencies live.
- Claims a second opinion can check without repository access.
- A record of what changed across an engagement.
- An explicit list of what nobody outside the supplier can currently confirm.
Where it does not
- Account ownership. That is a set of transfers, not an analysis.
- Contracts and negotiation.
- Judging whether the supplier is doing good work.
- Telling you whether to change supplier.
- Anything held outside the repository, beyond flagging it as unknown.
Questions people actually ask
No. Outsourcing development is a reasonable decision and often the right one. The problem is not the dependency — it is an unmeasured dependency, where nobody has established what would actually happen if the relationship ended, and everybody assumes somebody else has checked.
It applies more, not less. A long, good relationship is exactly where ownership questions stop being asked, accounts accumulate in the supplier's name, and everybody is comfortable. Nothing here is an accusation; a supplier who is behaving well will usually help you fix all of it in an afternoon.
Framed as risk management rather than suspicion, a competent supplier will recognise it as normal and may well have wanted it too — they carry risk from the arrangement as well. If asking who owns the domain causes a problem, that reaction is itself the most valuable finding.
Whether the production infrastructure and the domain are in accounts owned by your company. Everything else can be recovered with time and money; those two can leave you unable to operate your own product.