An owner told me in August that his developer "is basically telling me I have access to everything, but I don't." Twenty-five minutes later, with his screen shared, we had the real picture. He owned twelve landing pages, because they were on his GoDaddy account. He did not own the dashboard, because it ran on the developer's Render. He did not own his lead database, because it was a Google Sheet under the developer's Gmail. He did own his QuickBooks, because he had never handed it over, which was the best decision in the whole engagement.
He had paid for all of it. Paying is not owning. Here are the five questions that tell you which one you did.
1. Whose name is on the domain?
Log in to your registrar. Not the website, the registrar: GoDaddy, Namecheap, Google Domains, wherever the domain was bought. Are you the account owner? Is your email the recovery email? Are there delegate users, API keys, or "account access" grants you did not create?
If the answer to any of those is no or I do not know, stop reading and fix it first. Whoever controls the domain controls the website, the email that arrives at it, and every subdomain the developer built on it. This is the one item that can take a business offline.
"So you gave him access to your GoDaddy. That's why I was saying I'll need to get all the emails so I can really understand what he has access to. We're going to have to change your GoDaddy so that he can't break anything."
On the discovery call, after spotting a subdomain the developer had created2. Where does it actually run?
Open the thing you were shown and read the address bar. A URL ending in onrender.com, vercel.app, netlify.app, or a workers.dev subdomain means the application is running on somebody's hosting account. Ask whose. If it is theirs, you have a demo that they can turn off. That is acceptable during a build. It is not acceptable at the final invoice.
The fix is not always to fight for the account. In August, the dashboard on the developer's Render was not worth keeping. We let him shut it down. The fix for the parts worth keeping was a backup and a rebuild on the client's own accounts, which took less time than the argument would have.
3. Can you open the repository?
Code without a repository you can access is code you do not have. Ask for the GitHub, GitLab, or Bitbucket link and confirm you are an owner or admin on it, not a collaborator who can be removed. If the developer merged your project into their own repo, which happens more than you would think, ask for it to be separated and transferred. That request is reasonable and a professional developer will do it. In August the developer did it the same night.
No repository at all is a different finding. It means there is no backup, no way for a second developer to pick up the work, and no way to verify what exists. It usually means the code is on one laptop.
4. Whose account holds the data?
The "database" in a small build is very often a Google Sheet, an Airtable base, or a table inside a CRM the developer set up. Ask which account owns it. If you request access and cannot tell whether the request will go to your own employee or to the developer, you do not own the data.
Data ownership matters more than code ownership. Code can be rewritten. Three months of leads cannot be.
"If I were to request access, who's going to get that request? Your employee, or him? Because I can't tell who the request is going to go to."
Looking at the lead sheet on the call5. What keys are in the code?
This is the one owners never ask, because they do not know it exists. When a developer connects your CRM, your registrar, your email tool, or an AI service to the system, they use an API key. That key lives inside the code or the hosting configuration. It keeps working after you change your password. It keeps working after you remove their login. The only thing that stops it is regenerating the key inside the service it belongs to.
Ask directly: which API keys are in the system, for which services, and can we rotate them today? In August the developer volunteered the GoDaddy key on the handoff call. I rotated it while we talked. A client alone would never have known it was there.
What the answers cost to fix
| Question | Bad answer | Fix | Effort |
|---|---|---|---|
| Domain | Developer is owner or has API access | Reclaim ownership, rotate password and keys, remove delegates | 30 minutes if you are still on the account. A registrar dispute if you are not. |
| Hosting | Runs on their account | Back up, recreate on yours | Hours to days depending on what is worth keeping |
| Repository | Theirs, or none | Transfer or export; if none, treat the code as unverified | Same day with a cooperative developer |
| Data | Sheet or table on their account | Export, recreate under your Workspace, repoint the forms | An hour, plus verifying nothing was missed |
| Keys | Unknown keys in code | Inventory and rotate every one, in the service that issued it | An hour on a screen share |
If you cannot answer three of the five, you do not have an ownership problem you can solve by email. You have a takeover. The takeover page walks through it in order, and the 25-point checklist will tell you how urgent it is. If you can answer all five and the answers are good, congratulations. Put them on one page inside the system, so the next person never has to ask.
Every Heed build ships with that page from day one. It is called the continuity plan, and it is the reason this article is never about us.