The handoff test: what “you own the code” should actually mean.

“You own the code” is one of those phrases that sounds like a complete answer and is actually the start of a longer question. Owning the domain — the subject of the ownership audit — is table stakes. It's necessary and it's not sufficient. A business can hold the domain, the hosting account, and every credential imaginable and still not genuinely own its software, because ownership of code specifically has its own separate list of things that have to be true.

What ownership beyond the domain actually requires

Five things, each independently necessary, and each one a place where "you own it" quietly turns out to be false in practice:

• The repository lives in an account you control. Not the developer's personal GitHub, not the agency's org with your project as one repo among fifty clients. If a vendor disappears or the relationship ends badly, a repo sitting in their account is a repo you have to fight for, not one you already hold.
• The IP assignment clause is explicit, in writing, and actually assigns. Work-for-hire language varies by jurisdiction and by contract, and "we built it for you" in conversation is not the same as a contract clause that assigns the intellectual property to your business specifically. This is the single most commonly assumed-but-unverified item on the list.
• Third-party licenses are compatible with your business, not just the build. A site or app built with libraries, themes, or paid components licensed to the developer personally — rather than to your business — can leave you unable to legally continue using or modifying the software once the relationship ends, even though the code itself sits in your repo.
• Environment variables and secrets are documented and accessible to you. API keys, database credentials, third-party service tokens — if these exist only in a vendor's password manager or, worse, hardcoded somewhere only they remember, the code you technically own doesn't actually run without them.
• Infrastructure accounts are registered to you, not delegated from someone else's. Hosting, cloud provider, CDN, monitoring — the same principle as the domain audit, applied to every service the software depends on to function in production.

Every one of these can be individually true or false, independent of the others. A business can own its domain and its repo and still be locked out of production because the infrastructure account belongs to a developer who's stopped answering emails.

The vanish-test

The single question that collapses all five items into one practical check: if this vendor vanished tomorrow — no warning, no handoff call, gone — could another competent developer pick this project up and be productive within a week?

Not "could they eventually figure it out." A week. That's the bar, and it's a fair one — a properly documented, properly owned codebase should be legible to a new developer in that timeframe, because the alternative is a business that's effectively hostage to one person's continued availability and goodwill, indefinitely, without ever having agreed to that arrangement explicitly.

Running this test honestly usually surfaces one of two outcomes. Either the answer is genuinely yes, in which case you've confirmed something worth knowing and can stop worrying about it. Or the answer is uncertain or no, in which case you've found a real, fixable problem while there's still time to fix it calmly — rather than discovering it during an actual emergency, when the vendor really has vanished and the fix has to happen under pressure.

What a real handoff package actually contains

Concretely, not vaguely, a handoff package that would pass the vanish-test contains:

• Repository access, in an account you control, with full commit history intact (not a fresh export with history stripped).
• A written IP assignment clause, referencing the specific work, in the actual contract.
• A list of every third-party library, theme, or paid component used, with license terms and renewal status for each.
• A documented list of every environment variable and secret the application needs to run, with those credentials either already in your possession or a clear, immediate process for obtaining them.
• Infrastructure accounts (hosting, DNS, cloud provider, any third-party service) registered under your business's ownership, with the vendor holding delegated access rather than the reverse.
• A README or equivalent covering: how to run the project locally, how deployment works, and where the genuinely non-obvious decisions are — the things a new developer would otherwise have to reverse-engineer from the code alone.

None of this is exotic or expensive to produce. It's mostly documentation discipline applied consistently from the start of a project, which is exactly why it's so often missing — it's invisible right up until the moment it's urgently needed.

Run the test on your current vendor this week

You don't need to wait for a crisis to check this. A reasonable, low-friction way to run the vanish-test on whoever built your current site or app: ask for exactly the six items above, framed plainly — "for our own records and business continuity, can you send over the repo access details, the IP assignment clause from our contract, the third-party license list, and confirm the infrastructure accounts are under our name."

A vendor who's operating the way they should will produce this without friction, often within a day, because they already have it organized. A vendor who hesitates, deflects, or takes weeks to assemble something that should already exist has just given you a genuinely useful answer — not about the code specifically, but about how much you can rely on the relationship continuing to work smoothly. Better to learn that now, on your own schedule, than to learn it later, on theirs.