Why Should Clients Own Every Account Behind Their Site?

Whose name should be on the accounts that run your website and automations?

Yours, as the client, every time. The Webflow workspace, the domain, the HubSpot portal, the Zapier or Make account, the Airtable base: all of it should belong to the business that pays for it. The person who builds it should be invited in, not the other way around.

This sounds obvious until you try to leave a freelancer or a contractor and discover the domain is registered to them, the automations run on their personal Zapier plan, and the only admin on the CRM left two years ago. Untangling that can take weeks and put live lead flow at risk.

I build websites and the automations behind them for lead generation. That work only has value if the client can keep running it after I am gone. So my position is simple: the client owns every account, and I work inside them as an invited user.

Why does account ownership matter so much?

Because whoever owns the account controls the business asset. If a builder owns the Zapier account, they own the lead routing. If they own the domain, they own the website's address. Ownership decides who can change, export, or shut down the systems your pipeline depends on.

Most of the time, nobody acts in bad faith. Ownership just drifts. A contractor sets up a trial to get moving fast, the trial becomes the real account, and nobody moves it later. Years pass, the contractor moves on, and a password reset now goes to an inbox nobody at the company can read.

The risk is not only a dispute. It is also simple continuity. When an automation breaks at night, the person who can fix it needs access. When billing fails on an account tied to someone else's card, a working system can stop with no warning to the people who rely on it.

Which accounts should the client always own?

The domain registrar, the website platform workspace, the CRM, every automation platform, every database that feeds the site or CRM, analytics, and Google Search Console. If losing access to it would stop leads, break the site, or hide your data, the business should own it outright.

For a typical B2B setup I work on, that list looks like this in prose. The domain and DNS. The Webflow workspace and site. HubSpot or Salesforce. Zapier, Make, or n8n. Airtable and any sync tool like WhaleSync. Enrichment tools such as Clay or Apollo. Google Analytics, Google Search Console, and Google Tag Manager.

The production automations I have built show why this matters. Ajust runs on Airtable and WhaleSync and has delivered 25,000+ cases and helped 400,000+ people. Kismet Health runs HubSpot through Zapier. Systems at that scale are core infrastructure for the business, and core infrastructure should never depend on an outside builder's login.

How should a builder get access instead?

Through invited user seats or roles inside the client's accounts, with the least access needed for the job. Most modern tools support inviting a collaborator with a defined role. That way the builder can do the work, the client keeps control, and removing access later is a single click.

The setup order matters. On day one, the client creates the accounts, or confirms which existing accounts to use, and invites the builder. If the client does not know how to create an account in a tool, the builder can walk them through it on a call. It takes minutes and saves months of untangling later.

Billing should follow ownership. The client's card pays for the plans. If a builder fronts a cost to get started, it gets moved to the client's billing before launch. A system that runs on someone else's payment method is one expired card away from stopping.

What about tools the builder already pays for?

Keep the builder's own tools for the builder's own work, and never run a client's production system on them. A builder can use their own accounts for drafts, tests, and internal notes. The moment something touches the client's live leads or live site, it moves into the client's accounts.

This is the line I hold most firmly. It is tempting to run a quick Zap on your own plan because it is already paid for and set up. That shortcut creates a hidden dependency. The client does not know their lead routing lives somewhere they cannot see, and neither does the next person they hire.

The same rule applies to API keys and connections. If an automation connects to the client's CRM, it should use credentials the client controls, ideally a dedicated integration user, not a key generated from the builder's personal login.

How does client ownership change pricing and scope?

It barely changes the price and it clarifies the scope. Setting up accounts under the client's name is a small task at the start of a project. I use fixed-fee pricing, with most projects between $1,000 and $10,000, and account setup belongs inside that fixed plan so nobody is surprised.

It also makes handover a real step instead of a hope. When the project ends, there is nothing to transfer, because everything already belongs to the client. Handover becomes documentation and training, not a scramble to move accounts and reconnect integrations.

I wrote about the documentation side of that in automation handoff documentation for clients. Ownership and documentation together are what make a system survive the builder leaving.

What should you do if a past builder still owns your accounts?

Make a list, ask politely, and move one account at a time, starting with the domain. Most past builders will help transfer ownership when asked. Move the domain first because it controls everything else, then the website workspace, then the CRM, then automations, testing each one after the move.

Automations need extra care, because moving a Zap or a Make scenario to a new account can break connections and run history. Plan a short window, rebuild or import the workflow in your account, reconnect the apps with your credentials, test with real data, and only then turn off the old one. Do not delete the old version until the new one has run cleanly for a week or two.

For the broader question of who is responsible once the builder is gone, see who owns an automation after the builder leaves.

Is there ever a good reason for the builder to own an account?

Rarely, and only with a written plan to transfer it. A short pilot, a prototype the client may never use, or a tool the client explicitly does not want to manage can start in the builder's account. Even then, both sides should agree in writing when and how ownership moves.

The test I use is simple. If this system stopped tomorrow, would the client's business notice? If yes, the client owns it. If no, a temporary arrangement can work, as long as everyone knows it is temporary.

It is also why I ask for access early in a project. Seeing a client's real accounts before scoping shows who owns what and where the risks are. I explained that habit in why I ask for access before I send a proposal.

What should you do next?

List every account behind your website and lead flow, and write down who owns each one and whose card pays for it. Move anything owned by an outside builder into your business's name, starting with the domain. For new projects, create the accounts yourself and invite the builder in.

Ownership is not about distrust. It is about making sure the systems that bring in revenue belong to the business that depends on them. A good builder will welcome that, because it makes the work cleaner for everyone.

If you want help auditing who owns what in your stack, or building new systems the right way from the start, reach out and let's chat.