The website belongs to whoever signed up for the accounts
An AI website tool does not start with design. It starts with accounts: a hosting space, a domain, a deployment pipeline, a form endpoint, an analytics property. Someone clicks through those signups, and that someone becomes the practical owner of the website — no matter who paid for it or whose name is on the invoice.
The reason this goes unnoticed is that the result looks like the whole deliverable. A finished website is visible; the infrastructure behind it is not. It stays invisible until the day you need to change a phone number, move to a new domain, or add a page and cannot get in.
By then the person who clicked through those signups may be a freelancer you no longer work with, a former employee, or the founder’s personal account that nobody else can access.
What AI genuinely handles well
Speed from idea to something real. A plumbing company that needs a website with service pages, a quote form and a map can see a working version the same afternoon instead of waiting weeks for the first round of design. That changes how fast decisions get made, because there is something concrete to react to.
Structure and boilerplate. Headers, footers, contact pages, cookie notices, sitemaps, mobile layouts — the parts every business website needs and no customer will ever compliment. AI produces them consistently and quickly, which frees the budget for the pages that actually compete.
First-draft copy that gives you something to argue with. Editing a mediocre paragraph is faster than facing a blank page. The draft is rarely publishable, but it moves the conversation from “what should we say” to “this is wrong, here is what we actually do”.
Where ownership quietly gets lost
The accounts are personal by default. A site deployed from a private repository, a domain registered to a personal e-mail address, form submissions arriving in one person’s inbox. Nothing breaks while that person is around. It breaks the first time a DNS record has to be changed and the only account that can change it belongs to someone who left last spring.
Nobody wrote down how the site works. An AI-assisted build often ends up with a deployment setup nobody documented: the content lives in one place, the styles in another, the form handler somewhere else again. When a customer reports that enquiries stopped arriving, someone has to spend three hours reconstructing the chain before they can even diagnose it.
Nobody on the team can make a small change. If updating opening hours means asking the person who built the site, you do not own a website. You have a dependency with a monthly bill. The test is simple: can a colleague who has never touched the code change a sentence and publish it without help?
Nobody agreed what happens on the last day. Ask what you are entitled to take with you when the working relationship ends — the code, the content, the domain, the analytics history — and many projects have no answer. A website you cannot leave is not an asset.
How to make the handover a deliverable
Decide the owner of every account before the build starts. Domain, hosting, deployment, analytics, form endpoint, e-mail. Put them under company-controlled addresses with at least two people able to log in. This is a five-minute conversation at the beginning of a project and a month of pain if it is skipped.
Ask for a handover document, not a list of logins. The document should answer where the site is hosted, how a change reaches production, which integrations are connected and what they do, which credentials exist and where they are stored, and what renewals cost each year. A login list tells you that doors exist. A handover document tells you which door to open for which task.
Test the handover while the builder is still available. Have someone who did not build the site make one small change and publish it on their own. Until that works, the project is not finished, whatever the plan says.
Agree the exit path in writing. What happens on the day you stop working together? Can you move the site, keep the domain, keep the content and hand the whole thing to someone else? If the answer is unclear, negotiate it now, while everyone is still on good terms.
Why we treat handover as part of the build
We build with AI tools because they shorten the distance between an idea and a working page. That speed is only worth something if the result stays under your control afterwards. So the handover is not paperwork we do at the end — it is part of the work: company-owned accounts from day one, a written description of how the site runs, and an editing model that lets your team change ordinary content without a developer.
A website assembled in an afternoon still has a five-year life ahead of it, full of price changes, new services and staff turnover. The build is not complete when the pages look right. It is complete when the site can be run without the person who made it.
Related service: Web design and content strategy