What you should own after a studio engagement

Website code ownership, after a studio engagement, means the company can run the site without asking permission. Four things should be in your name: the repository, the domain, the analytics, and the logins that edit the content. A studio that keeps those is a dependency. A partner hands them over, explains them once, and stays available without becoming a gate.

The handoff is incomplete if the site looks finished and you still cannot change a headline, point the domain, or see whether anyone visited. Visual approval is one deliverable. Access is the other.

The repository

The repository is the product you can take elsewhere. It should live in an organization your company controls: GitHub or the equivalent, with the company as owner and the studio as a collaborator it can remove. History should be intact, so a later engineer can see why a decision was made.

You should be able to clone it, read a short README, and find the homepage. The README needs the command that runs the site, the command that checks it, and a list of environment variables by name. The values of secrets stay in a password store you control, not in the README and not only in the studio's head.

On a Hanabi build the code is the kind of project another engineer can enter: Next.js, React, TypeScript, and the styles in the repo. Hosting may be Vercel. The host is a convenience. If the project on the host is owned by the studio's team account, you do not yet own the deployment. Transfer the project, or create the company's own project and deploy from the company's repository. Confirm you can ship a preview without the studio clicking the button.

A zip file emailed at the end is a weak copy of this. It has no history, and it is already out of date if anyone kept working. Insist on the live repository.

The domain and the DNS

The domain is the company's name on the public web. The registrar account should be yours: the login, the recovery email, and the payment method. A studio can be a technical contact. It should not be the only person who can renew the name or change the records.

DNS is the list of records that point the name at the host, the email provider, and anything else you depend on. Ask for an export or a written copy of the records before a launch changes them, and keep that copy. If a record is wrong, the person who owns the account can put the previous values back.

Email on the domain is part of this, even when the website project did not include it. Forms that send to work addresses, and the inboxes those forms reach, should be accounts your company pays for. A form that posts only into a studio inbox will go quiet when the engagement ends.

Analytics and the other windows

Analytics tell you whether the right people found the site. The property should be created under a company account. You should be able to open it after the studio's access is removed and still see the history. If the studio's personal login is the owner, have them transfer ownership before the last invoice, not after.

A few other windows belong in the same list.

• The error log or the host's log access, so a failed deploy is visible to you.
• The search console property for the domain, if you care which queries reach the site. Verify it with a method you control, such as a DNS record.
• The accounts for fonts, stock images, and any paid plugin, with licenses that allow the company to keep using them.
• The map or form provider, if the page depends on a key. Keys should be in your environment, revocable by you.

You do not need to watch these every day. You need to be able to open them on the day something breaks, without a scavenger hunt through old email.

Content logins

Whoever edits words needs a login that survives the engagement. That includes the CMS, if you have one, and any collection of brand files the team is expected to use.

Hanabi's client portal is the concrete version of the file cabinet: brand files, documents, and project updates after delivery. It is useful because the logo and the guidelines are findable in one place. It does not replace the repository, and it does not replace the CMS login. A client who can download a logo and cannot edit the homepage still has a gap. Ask for both.

Shared passwords in a chat thread are not logins. Each person who needs access should have their own account, and you should know how to remove the studio when you want to. Two-factor recovery codes belong in the company password store on day one. The day someone leaves is a bad day to discover the codes were on their laptop.

Write down where each kind of content lives. Marketing pages in the repo. Articles in the CMS. Logos in the portal. If that map is only in someone's memory, the ownership is theoretical.

What "handed over" looks like in a meeting

Spend one meeting on access, separate from the visual review. Open each account from a company email while the studio watches. Clone the repo. Load the site locally or open a preview you triggered. Change a draft headline and discard it. Open the registrar. Open analytics. Open the CMS. Save the recovery codes.

Google's helpful-content guidance treats it as a good sign when visitors can tell who created the content, and when the page would still help someone who came to you directly. Both stay true when the company can still change the site as the offer changes. Ownership is what makes the "who" remain the company after the studio has gone home.

If any login fails in that meeting, the engagement is not finished. Fix it before you call the project done. A follow-up week of "we'll transfer that" is how dependencies quietly stay in place.

The design handoff, the files, and the place those files live are the other half of this. The handoff that makes a redesign usable after the studio leaves covers that side. This piece is the accounts. You want both.

If you are about to start, put ownership in the first conversation. An intro call is the right place to ask who will own the repository, the domain, and the content logins at the end, and to walk away from a studio that treats those as its own assets.