You control your website when your company — not the agency — holds the domain, DNS, hosting, source code, CMS and operational accounts, and someone on your side can log in, publish, rebuild, deploy and remove the supplier's access. A live site proves none of that. Run each asset through the owner check below before you sign acceptance.
About to accept a build? WebStackRank hands over with client-owned accounts from day one — see how web development consulting structures acceptance, or ask about your handover.
Why must ownership be decided before development starts?
Because ownership obligations belong in the scope of work before a line of code is written. Left until launch, ordinary deliverables become a negotiation — and the buyer loses the leverage to reject an incomplete handover. Agree these at kickoff:
- Which accounts open in the client's name from day one. Domain, hosting, analytics and transactional email are cheaper and cleaner to open under the client than to migrate later.
- Where the source code lives. Name the client's repository organisation as the home for the code, with the agency added as a collaborator — not the reverse.
- What counts as a complete, buildable handover. Define up front that the deliverable includes dependency records, environment requirements and build instructions, so an empty repository or a running site alone cannot pass as done.
- When each item transfers. Tie each asset to a milestone, launch or final payment, and have qualified counsel review any conditions on IP transfer.
- Who signs off, and against what test. Name the person on your side who performs the control checks at acceptance. An agency demonstration proves the agency has access; it does not prove you can operate alone.
Choosing the right partner matters as much as the clauses — read how to choose a web development company and record every requirement in the annotated RFP template before you sign. The website development process shows where these ownership decisions get recorded during a typical build.
How do you turn "we'll give you access" into a real deliverable?
"We will give you access" is not a deliverable — it names no owner, no recovery route and no test. Replace it, for every asset, with three concrete things: the person or company account named as owner, the recovery method that person controls, and the specific action they will perform at acceptance to prove control.
This is also a security decision. Verizon's 2025 Data Breach Investigations Report — over 22,000 security incidents and 12,195 confirmed breaches — found stolen credentials in 22% of breaches, and 88% of basic web application attacks involved compromised credentials (Verizon; Bluefin's analysis). Shared logins and agency-controlled accounts are not just an ownership risk; they are an attack surface. Keep secret values in the company's approved credential manager, never inside the handover inventory itself.
The complete handover inventory: a named owner for every asset
This inventory connects each asset to the evidence you should receive, the party that should own it, and one action a client can perform to confirm control. A list of passwords establishes none of these things.
| Asset group | Evidence to receive | Named owner | Control check the client performs |
|---|---|---|---|
| Domain registrar | Registrar access, registrant details, renewal method, recovery route | The client company, in an account it controls | Inspect the domain record, billing and authorised users directly |
| DNS records | Administrative access and a dated export of active records | The client, or a provider account it administers | View and export the A, CNAME, MX and TXT records without agency help |
| Source code repository | Source, history, dependency record, environment requirements, build instructions | The client's repository organisation | Clone into a clean directory and produce the documented build |
| Hosting and deployment | Administrative role, billing control, environment inventory, release steps | The client, or a documented transferable arrangement | Deploy a working copy to a non-production environment it controls |
| CMS administrator account | A named administrator account and client-controlled recovery method | A person accountable to the client | Edit content, manage settings, and add or remove users |
| Analytics and operational services | Access to analytics, tag management, transactional email, search tools, payment services, live integrations | The client as primary owner wherever the service supports one | Inspect users, connected domains, billing and active credentials |
| Design source files | Editable files, exported assets, font records, available licence documentation | The client's design workspace or controlled file store | Open and edit the original source instead of recreating it from screenshots |
| Operating documentation | Environment map, release steps, backup method, recovery notes, known limitations | The client's document store | A colleague who did not build the site can identify every system and follow the release steps |
WebStackRank's published pricing uses fixed project pricing without mandatory retainers and gives the client ownership of the code at handover — check the pricing page for the current offer, and how much a website costs in 2026 for how that pricing is structured. If you are planning a rebuild rather than a first build, the website redesign SEO migration checklist protects the assets this inventory tracks.
How do you score handover readiness before signing off?
"It feels mostly done" is not an acceptance standard. Score each of the eight asset groups above: 0 if not delivered, 1 if delivered but the control check has not passed, 2 if delivered and the control check passed. Maximum: 16.
The acceptance rule has three parts, and all three must hold:
- No asset may score 0.
- The two highest-risk assets — the domain registrar and the source code repository — must both score 2.
- The total must reach 14 of 16.
Worked example from a routine marketing-site handover: Domain 2, DNS 2, source repository 1 (a clean clone failed to build — two private packages and the environment template were missing), hosting 2, CMS 2, analytics and services 1 (the transactional-email account was still in the agency's name), design files 2, documentation 1 (backup and recovery steps were written but never tested). Total: 13 of 16.
Thirteen out of sixteen looks close enough to accept — and that is exactly the trap. The source repository scored 1, which breaks the highest-risk rule, and two assets sit at 1. So this handover is not accepted: the repository build and the transactional-email transfer become named acceptance items with owners and dates. A high score never overrides a blocker, which is why the score and the pass rule are separate tests rather than one average.
Which contract clauses lock in ownership up front?
These three decisions describe the commercial outcome you need, not legal wording. They may not suit every jurisdiction — ask qualified counsel to review the final drafting.
- IP assignment for custom deliverables. Define which custom code, designs and content transfer to the client, when the transfer occurs, and what is excluded. Pre-existing supplier tools, open-source software, fonts, plugins and third-party components may carry separate terms. Access to a finished website is not the same as a documented transfer of every custom deliverable.
- Credential transfer timeline and acceptance owner. Attach the inventory above to the acceptance process. Name the person who confirms receipt and the point at which each account must be under client control. A live website is insufficient evidence — it can run while the buyer lacks registrar, hosting or repository authority.
- No lock-in and a documented exit path. Require the proposal to explain how the site can be exported, rebuilt or moved, including any limits the chosen platform creates. This does not condemn every managed platform; it means the exit consequence must be visible before the platform is approved.
Third-party exposure is the fastest-growing breach vector in the Verizon data: third-party involvement in breaches doubled to 30% in the 2025 DBIR, and ransomware appeared in 44% of breaches with a median payout of $115,000 (Keepnet's DBIR summary). "Businesses need to invest in robust security measures, including strong password policies, timely patching of vulnerabilities, and comprehensive security awareness training for employees," says Chris Novak, Vice President of Global Cybersecurity Solutions at Verizon Business. The exit-path clause is the contractual half of that advice — put both in the RFP and re-check them in core web development services scoping.
What are the four ownership traps to watch for?
Each trap begins with a convenient arrangement and ends with a business action the buyer cannot complete alone.
- Agency-owned domain account. The site works normally while the domain sits in the supplier's registrar account. The dependency surfaces the moment you need to change DNS, replace the supplier or recover the domain. Safer: a company-controlled registrar account with a named agency user where delegated access is supported.
- Reseller hosting with no agreed transfer route. You get a CMS login but no hosting administration, billing relationship or deployment path. Leaving then depends on an export whose contents and timing were never defined. Record whether the account itself can transfer — and exactly which files, databases and configuration will be supplied if it cannot.
- Shared administrator login. Three marketers and the agency share one admin login during the build. When the project ends and they rotate the password, all three internal users are locked out at once, and the recovery email points to the agency's mailbox. One shared credential hides who changed what and makes selective removal impossible. Use named accounts and keep at least one recovery route under company control.
- Proprietary platform with no usable independent build. Editable content does not mean portable source. Before approving a proprietary page builder or hosted arrangement, ask the supplier to demonstrate the agreed export, rebuild or migration route — and to document what cannot move.
If any of these describe your current site, the redesign migration checklist is the safest way to move, and how to choose a web development company helps you vet the next supplier against this exact list.
How do you verify ownership without risking production data?
Run a five-part control test on client-controlled accounts, using non-production environments, harmless reversible edits and no changes to live DNS or customer data. Passing all five means your team can access, edit, rebuild, deploy and govern the site without the agency's identity:
- Independent access test. From a browser session not authenticated by the agency, open the registrar, DNS, hosting, repository, CMS and material third-party services through named client accounts, and confirm recovery routes.
- Editing test. Make a harmless, pre-agreed content edit through a client CMS admin account, publish it, verify it, then reverse it. Record the person and account used.
- Clean build test. Have a technical reviewer clone the repository into a clean directory, install the documented dependencies and produce the expected build. Missing private packages, environment instructions or config values are acceptance issues.
- Staging deployment test. Deploy that build to a non-production environment the client controls, and check key pages and agreed integrations without touching production DNS or live customer data.
- Access-revocation test. On a non-critical service, confirm the client administrator can remove and restore a named agency user. Never test this on production-critical access without an agreed recovery plan.
Record each failed action as an acceptance item with an owner, required evidence and resolution date. A support agreement can continue after handover — but it should remain a choice, not the only way to keep the site running. The website development process shows how acceptance gates fit a normal delivery cadence, and web development consulting can run the verification independently.
Frequently asked questions
Do I automatically own my website after an agency builds it?
No. Paying the invoice and receiving a live website does not by itself give you control of the domain, hosting, source code or CMS accounts. Ownership exists only when those assets sit in accounts your company administers and you can operate them without the agency. Contract interpretation should be handled by qualified counsel.
What should I ask for at website handover?
Client-controlled access to the domain, DNS, hosting, repository, CMS and operational services, plus editable design files and usable build, deployment, backup and recovery documentation. Do not accept an emailed URL or password as complete evidence — confirm the account owner, billing contact, recovery route, administrative role and control check for each asset.
How do I know I am not locked into an agency?
You are not operationally locked in when your team passes the independent access, editing, clean build, staging deployment and access-revocation tests using company-controlled accounts and documentation. Ongoing support can still be useful; the distinction is whether you can change suppliers or operate internally without losing control.
What is the minimum passing handover score?
14 out of 16, with no asset at 0 and both the domain registrar and source code repository at a full 2. A high total never overrides a blocker on a highest-risk asset.
Should credentials be listed in the handover inventory?
No. The inventory names systems, owners, recovery routes and evidence; secret values live in the company's approved credential manager. Given that stolen credentials appeared in 22% of breaches in Verizon's 2025 DBIR, this separation is a security control, not bureaucracy.
Who should review the handover before I sign?
Your named acceptance owner runs the control tests; qualified counsel reviews the IP and lock-in clauses; and your technical reviewer verifies the clean build. A named delivery lead on the agency side should countersign each item.
Close the handover without creating another dependency. Assign one person on the client side to own the inventory and the score, give every unresolved item a responsible party and an acceptance date — and if you want the next build done right from day one, start with web development consulting or contact the team.
