Sign in to your domain registrar and check which account holds the domain. “The developer owns our hosting account” is fixable while the developer answers, and the fix is the same on Vercel, Supabase, Stripe or any provider: an account you own, you in the owner role, billing or payouts in your name, the builder removed on a recorded date.
”The developer owns our hosting account”: what owning a provider account actually means
Provider account ownership means four things are true for every service the product runs on: the company holds the account, a founder holds the owner role, billing or payouts are in the company’s name, and the previous builder has been removed or can be. An owner seat inside the builder’s own account is not one of them.
| Condition | The test | What the test does not prove |
|---|---|---|
| The company holds the account: created by it, or handed to it through the provider’s own ownership change (on Stripe the owner changes inside the existing account), on a company email at a domain the company controls | The sign-in email and the recovery email are addresses on your domain | Who administers that email domain. Whoever does can reach every inbox the recovery links go to, so the email domain gets its own row in the inventory |
| A founder holds the provider’s owner role: Owner on Vercel, Supabase and Firebase, the account owner on Stripe, the repository owner or an organization owner on GitHub | The members page lists a founder in that role | What sits above the account. A Google Cloud project inside the builder’s organization can show you as Owner while the organization stays theirs |
| Billing or payouts are the company’s: where the provider bills, the billing account and card; on a free plan, a note that no payment method is attached and who can add one; on Stripe, which takes its fee out of the charge amount, the bank account payouts go to | The billing page, or Stripe’s payout settings | Who paid before the move. Supabase and Google Cloud both bill the old account for usage up to the switch |
| The previous builder is removed, or holds a scoped role you can remove | The members page, and on GitHub each repository’s collaborator list | That the keys they could read have stopped working. Removing a person leaves every key they copied valid |
The four conditions and their tests are my working rule; the role names and the Stripe, Google Cloud and Supabase details in the cells come from each provider’s own docs. An owner seat inside the builder’s personal account or agency team is still the builder’s account, because they can remove you. That is my reading, and it is the case the table’s second row is there to catch. The reason it matters for an app somebody else set up: AI-built apps are often wired to accounts the builder created, and the business does not control what it does not own.
The services that count are every one the product depends on: the database, hosting, payments, email, AI and the domain, plus the code repository. The one-minute capability test for each account is already written up as the nine things that have to be in your name, and it is not repeated here; what follows is how you move each account and the record that proves you did. If you are the agency on the other side of this, the handover view is in delivering an AI-built app to your client. Owning the accounts is also one of the controls in secrets management, because whoever holds an account can read the keys stored in it.
What goes wrong without it
Each of the five failures below starts with an account in the wrong name, and each one points back to a condition in the table above. None of them needs bad intent. My reading is that the reason is usually speed, not malice: signing up with the email already open is the fastest way to get a database running on the first afternoon.
| What happens | What you see | The condition that was missing |
|---|---|---|
| The builder stops answering, and a fix is ready | Nobody you can reach holds the role that merges it, deploys it or changes a setting | A founder in the owner role |
| The builder’s card expires | The hosting or the domain lapses, and a lapsed domain takes the site and the company email down together | Billing in the company’s name |
| A falling-out | The account holder removes you, and the dashboard you used yesterday shows no access | The company holding the account |
| The builder’s own account is compromised | Nothing, until a change reaches production that nobody on your side made | The builder removed or in a role you can remove |
| A due-diligence reviewer asks who owns the accounts | The honest answer is “not us”, and no screenshot says otherwise | All four |
When the builder has already gone quiet, the first day looks different, and what to get back first when a developer leaves covers it, including who each platform allows to move what. The spend side is one more version of the same failure: a metered API key on the builder’s card has a limit you cannot see or change, which is where you cap monthly usage on a metered API. I cannot put an audit figure on how often accounts sit in the wrong name, because my audits read an app’s code, and the code does not show who holds the dashboard.
Picture a due-diligence review. The reviewer asks for the provider accounts, and the founder signs in to show the database and the host. The accounts belong to the freelancer who built the first version, and the founder is a member who can be removed, not the owner. Whoever owns the provider accounts can switch the product off. The lesson I take from it: the provider inventory later on this page clears that question, and a working login does not. The reviewer’s side of that conversation is part of owning an app someone else built.
Locked out of our own domain registrar: two different problems with one name
The phrase “locked out of our own domain registrar” covers two problems: the account holding the domain belongs to someone else, or the domain carries a registrar lock that blocks transfers. The first is solved with the account holder’s help or the registrar’s recovery process. The second is a status the registrar lets you remove, or removes on request.
The account problem has three routes, cheapest first. The account holder moves the domain into your account, or starts a change of registrant with the registrar. If nobody can sign in, the registrar’s own account recovery process is next; each registrar runs its own, so start from its help pages. Where the registrar will not unlock the domain for a transfer, the complaint route in the next paragraph applies, and ICANN’s registrant FAQ is plain about the starting point: “it is your right to transfer your domain name registrations between registrars.” The transfer code test and its timing rule sit with the nine ownership checks linked above.
The lock is a different thing. In ICANN’s page on locked domains, “Domain names can be locked to protect against unauthorized changes. This status may be called ‘Registrar lock’ or ‘Client Transfer Prohibited’ (or a similar term).” If the registrar does not let you unlock it yourself, ask the registrar, and if it “does not unlock the domain or provide you with a reasonable method to unlock it within five days from your request”, ICANN says to submit a Transfer Complaint. If you plan both a new registrar and new contact details, ICANN suggests you “may want to consider completing the transfer process before changing your contact information”, for the lock reason in the questions at the end.
My working rule prevents both problems: the domain lives in a company account at a registrar the founder chose, with auto-renew on and a second founder or officer as the backup contact. HTTPS, the DNS records and keeping the lock on once the domain is yours belong to add HTTPS to website.
How to move each provider into an account you own
Do this with the builder’s cooperation, while the relationship is good, and only through each provider’s own transfer or recovery process. Never try to reach an account through the builder’s email or a password reset they did not agree to. The steps below come from each provider’s documentation, read on 28 September 2026; none of it is a transfer I ran.
The order: domain first, keys last
The account order is fixed: domain and DNS first, then the company email console, the code repository, hosting together with the database, payments, and last the email sending, AI and other keys. The domain goes first because every password reset depends on it, and keys go last because moving them means rotating them.
That order is my working rule, and so is the step before it: create the company accounts yourself, each on a company email with a second factor turned on, which is where you implement two factor authentication. If the builder set up the company email domain, re-check those accounts’ recovery settings once step 2 is done, because until then the mailbox they recover through may still be administered by the builder.
- 01 Domain and DNS. Every password reset and every customer email depends on the domain, so it moves before anything else.
- 02 The company email domain's admin console, if the builder set it up. Every account below sends its recovery links to mailboxes on that domain.
- 03 The code repository. Hosting deploys from it, and nothing else is portable until it is in an account you hold.
- 04 Hosting, then the database, in one planned window. The link between them is what has to be redone: Vercel says integrations must be added again after a transfer, and a database connected through a Vercel integration is one of them.
- 05 Payments. The account stays where it is and the owner changes inside it, so it can wait until the rest is settled.
- 06 Email sending, AI providers, analytics, the error tracker and the rest. A new account here means new keys, which is why these go last.
Step 3 is the one the others lean on, and how to self host an exported app covers getting the code into your own repository and onto hosting you control.
What each move leaves behind
Each documented move leaves something behind that still points at the old owner. A GitHub transfer adds the original owner as a collaborator and keeps deploy keys and webhooks attached, Vercel integrations must be added again, and a Firebase project inside the builder’s Google Cloud organization needs a project migration to leave it.
Who may start each move, and each vendor’s full list of what travels, is in the transfer table of the developer-left article linked above. The table here keeps only what is left for you to finish once the move is done.
| Provider | The move | What it leaves behind | What to do after it | Vendor doc |
|---|---|---|---|---|
| Vercel (hosting) | A project transfer between teams, “with zero downtime and no workflow interruptions”; environment variables are copied, except those in vercel.json’s env and build.env | Integrations, which “must be added again after the transfer is complete”; usage is reset; for a subdomain such as blog.example.com, “the root domain example.com will remain on the origin Vercel scope” | Re-add each integration; move the vercel.json values into Project Settings; make the target a paid team, because the Hobby plan “restricts users to non-commercial, personal use only” | Vercel’s project transfer docs |
| Supabase (database) | A project transfer between organizations; it “cannot be used to transfer between different regions” | Usage and add-ons billed to the source organization “up until the transfer”; your own role in the target, which can be lower than it was | On a Free Plan target, Supabase checks the “two free project limit” and says that “in these cases, it is best to upgrade your target organization to Pro Plan first”; confirm you hold Owner in the target organization | Supabase’s project transfer guide |
| GitHub (repository) | A repository transfer; links and git clone, git fetch and git push redirect | ”The original owner of the repository is added as a collaborator”; webhooks, services, secrets and deploy keys “remain associated”; GitHub Pages sites are not redirected | Remove the old owner’s collaborator seat unless you chose to keep it; review each deploy key and webhook; update local clones with git remote set-url origin NEW_URL; a private repository moved to a GitHub Free account loses access to features like protected branches and GitHub Pages | GitHub’s repository transfer docs |
| Stripe (payments) | No move: ownership passes to a new Account Owner within the same account | Not stated in Stripe’s roles docs beyond the owner change itself | Check that payouts go to the company’s bank account; if the account was opened on the builder’s own business and bank details, the developer-left article covers when a new account is the realistic route | Stripe’s team roles |
| Firebase and Google Cloud | A founder added as Owner in IAM, and the project’s Cloud Billing account changed to the company’s | Charges incurred before the switch stay with the former billing account; a project inside a Google Cloud organization “may not have an Owner” | Run gcloud projects get-ancestors PROJECT_ID: if the output includes an organization and it is the builder’s, the move is a project migration into an organization the company holds | Firebase’s IAM overview |
| Domain | Covered in the registrar section above |
Google’s migration page explains why the last row is easy to miss: without permission on the parent organization, the Google Cloud console can make a project seem not associated with any organization, which is why the table uses the command instead. For email sending and AI providers, my reading is that the simpler route is a new account on your own domain, which means new keys and a re-verified sending domain, the reason they come last in the order. App store accounts follow a separate process, set out in the Apple developer account for non-technical founders.
Removing the previous builder without breaking production
- 01 List every place the builder has access: members pages, each repository's collaborator list, deploy keys, personal access tokens, OAuth apps they authorized, SSH keys on any server, the DNS account and shared password vault entries.
- 02 Downgrade before removing. Move them to the narrowest role the provider offers, then watch one deploy and one billing cycle go through.
- 03 Remove them, including the collaborator seat a GitHub transfer gives the original owner and any deploy key or webhook they added.
- 04 Rotate every secret the builder could read, because removing a member does not make anyone forget a key.
- 05 Write the removal date in the inventory, next to the provider.
Rotation has an order and an overlap window, both set out in how to rotate API keys safely; why a copied key keeps working after its owner leaves is covered in what is API key. Where the provider keeps a record, read it before you remove anyone: Stripe logs team members’ account activity for the past 180 days in Security history.
Keeping the builder on as a member with a scoped role is a valid end state. The goal is that you can remove them, not that you must. A scoped role is not on every plan, though. On Supabase, the “Read-Only role is only available on the Team and Enterprise plans”; on the plans below those, the narrowest role is Developer, with “content access to project resources”. On GitHub, “A repository owned by a personal account has two permission levels: the repository owner and collaborators”, collaborators on a private one get write access, and GitHub suggests moving it to an organization for “more granular access”. Where no scoped role exists, removal is the end state.
The provider inventory as an asset inventory: what a security reviewer means
An asset inventory in cyber security is the list of everything the company has to monitor and protect: in CIS Controls terms, devices and servers, cloud ones included. A small SaaS with no servers of its own still has laptops and phones on that list, and the provider inventory covers the other half, the services the product runs on.
The CIS Controls list, version 8.1, opens with Control 1, “Inventory and Control of Enterprise Assets”, whose own description names “end-user devices, including portable and mobile; network devices; non-computing/Internet of Things (IoT) devices; and servers”. It lists “Account Management” as Control 5 and “Service Provider Management” as Control 15, the one about “service providers who hold sensitive data, or are responsible for an enterprise’s critical IT platforms or processes”. In my reading, the provider inventory is the working list behind Controls 5 and 15 for an app like yours. When a customer’s security questionnaire asks about asset management and offboarding, the inventory answers the service and account questions in one document; the device questions still want a separate list of the laptops and phones the team works on.
How to verify it
Provider ownership is verified per service with five checks: a founder signs in with a company email, the role shown is the provider’s owner role, the billing or payout page shows the company, the member list shows the builder removed or in a scoped role you chose, and the recovery email and second factor are the founder’s.
The inventory is where the checks are recorded, one row per service, and a full set of filled rows is how you verify the founder is the owner on every provider. The template below has eight columns. The four rows are an example for an unnamed small SaaS, with placeholders where your details go; the company email domain comes first because every other row recovers through it.
| Provider | What it holds | Owning account email | Owner-role holder | Billing name | Second factor on | Builder access removed on | How to recover |
|---|---|---|---|---|---|---|---|
| Company email domain (admin console) | Every mailbox the other rows recover through | [founder]@[company domain] | [founder name], administrator | [company name] | Yes, founder’s device | [date] | [second founder’s admin account] |
| Domain registrar | The domain and its renewal | admin@[company domain] | [founder name] | [company name], [company card] | Yes, founder’s device | [date] | [registrar recovery email], [backup contact] |
| Hosting | The app, its environment variables and its domains | ops@[company domain] | [founder name], Owner | [company name], [company card] | Yes, founder’s device | [date] | [second owner], [recovery codes location] |
| Payment provider | Customer payments and payouts | finance@[company domain] | [founder name], account owner | Payouts to [company bank account] | Yes, founder’s device | [date] | [recovery email], [recovery codes location] |
Finding the providers you forgot is the hard part of filling it in. My working rule is to read four places: the environment variable names in the hosting dashboard, the DNS records (a verification record usually names the service that asked for it), the company card statement, and the repository’s integrations page.
- 01 A founder signs in with a company email in a private browser window. Evidence: the signed-in page.
- 02 The role shown is the provider's owner role, and on Google Cloud the project's parent is no organization or one the company holds. Evidence: a dated screenshot of the members page.
- 03 Where the provider bills, the billing page shows the company's name and payment method; on a free plan, a note that none is attached and who can add one; on a payment provider, the payout bank account is the company's. Evidence: a dated screenshot.
- 04 The member list, and on GitHub each repository's collaborator list, shows the builder removed or in a scoped role you chose, with the reason written down. Evidence: the same members screenshot.
- 05 The recovery email, phone and second factor are the founder's, and a founder administers the company email domain. Evidence: the security settings page.
Store the screenshots with the inventory. Re-run the checks when anyone joins or leaves, and about once a quarter otherwise; that interval is my working rule, not a standard.
In the sprint, deliverable 2.8 is verified this way: produce an inventory listing each provider, the owning account, the owner role holder, and the date the previous builder’s access was removed.
Where the sprint does this
The verification line above belongs to deliverable 2.8, which moves every service the product depends on (database, hosting, payments, email, AI, domain) into an account the founder owns, with the founder as the owner role, billing in the founder’s name, and any previous builder removed. Deliverable 1.11 enforces a second factor on every owner and admin account, in the application and on every provider dashboard behind it, with recovery codes stored in the owner’s vault. Deliverable 7.11 keeps the application in a version-controlled repository and on a hosting account the founder controls, deployable through a documented pipeline, independent of the tool that generated it. Among its items, deliverable 7.13 locks the registrar, documents the DNS records and confirms renewal ownership. Deliverable 13.1, the production readiness report, delivers the result for every scope item, the work completed and its verification evidence, and is verified this way: account for all 123 IDs; keep failures visible until resolved and explain genuine non-applicable items. Where it stops: hosting, paid tools and API usage are paid through your accounts, and we explain any required costs before enabling them; legal advice and certification are separate services. The full wording of each one, starting with deliverable 2.8 in the published scope, is on that page.
Common questions about who owns the accounts behind an app
Who owns a domain legally?
The registrant, the holder named on the domain’s registration record: ICANN’s registrant FAQ uses “a registrant or registered name holder” as other names for the domain name holder. The registrar account is the practical control, because a change of registrant starts with the current registrar, which is why both should be the company.
Nothing on this page is legal advice. A dispute with a developer over who owns a domain or an account is a contract question for a lawyer where you are.
How can I verify the ownership of a domain name?
Search the domain in ICANN Lookup at lookup.icann.org; in ICANN’s words, “The ‘Registrar’ field shows you who your registrar is.” Then sign in to that registrar: if the domain is listed in an account the company holds, and the registrant contact is the company, the domain is yours in practice.
How long is a domain locked after transfer?
Registrars “also have the option of denying a transfer request within 60 days from when you last transferred the domain name to a different registrar”, in ICANN’s words. A change to the registrant name, organization or email address starts a 60-day Change of Registrant lock, and some registrars “may provide an option for you to opt-out of this 60-day lock period”, though “the registrar does not have to offer this option”.
Is a developer the same as an owner?
No. On Vercel, Supabase and Stripe, a developer and an owner hold separate roles, and the developer role cannot change who the owner is. Vercel’s Developer role can deploy but “cannot invite new team members”, and on Vercel “role changes, including assignment and revocation of team member roles, are an exclusive capability of those with the owner role”.
What is a hosting account?
The account at the company that runs your app’s servers or functions, holding the project, its environment variables, its domains and its bill. Whoever holds it can deploy, read the keys kept there and stop paying, and that bundle is why it belongs in the company’s name.
The checks in this guide show you where the app is open. The sprint below closes those gaps, tests the result and writes the evidence down.
Built it with AI. Now it has to hold up for real customers.
The Production Hardening Sprint takes the app you already have and builds the production foundation underneath it. Authentication and access rules, payments that stay consistent, error handling, monitoring, backups, automated tests and a documented handover. Our engineers work inside your existing codebase for ten working days. All 123 deliverables are included, and you get the evidence for each one.
See the Production Hardening Sprint → 
$2,500 fixed price · 10 working days · One codebase