Do You Own Your Website? Check the Contract and the Controls

The legal default is more nuanced than “the developer owns it”

The U.S. Copyright Office says copyright normally begins with the human author when an original work is fixed. It also recognizes important exceptions and contractual changes. An employee's work created within the scope of employment can be a work made for hire. Specially commissioned contractor work qualifies as work made for hire only when statutory conditions are met, including a signed agreement and one of the listed categories.

That means the popular sentence "your developer owns your entire website by default" is too broad. A website combines many things: client content and trademarks, newly written code, pre-existing code, open-source packages, stock media, fonts, platform services, data, and configuration. Different rules and agreements can apply to each.

The U.S. Copyright Office also explains that a copyright transfer generally must be in writing and signed by the owner of the rights conveyed. A good contract therefore does not rely on a slogan. It identifies the deliverables, rights, licenses, exclusions, payment condition, and transfer event. Counsel should adapt that language to the parties and governing law.

It is worth being clear about which way that nuance cuts, because the correction can be read as reassurance and it is not one. The reason the popular sentence is too broad is that a website is many works at once, not that a client is likely to own the code by default. On the code an outside developer writes for you, the statutory route to work-made-for-hire treatment needs both a signed agreement and one of the categories the statute lists, and commissioned website code generally does not sit in those categories. That is precisely why the signed-writing requirement matters so much in practice: where a contract says nothing, the safe assumption is that the rights in that code did not move to you, whatever the invoice says.

The practical consequence is small and unglamorous. If your agreement is silent on ownership, you do not have an argument to win later, you have a document to fix now, ideally before the next payment. That is a conversation, not a dispute, and it is far easier while everyone is still pleased with the work. This remains general information rather than advice on your situation.

Does a “work made for hire” clause mean you own the website?

This is general information about US copyright law rather than advice on your situation, and governing law varies. But it is worth knowing before you accept a reassurance, because the two phrases are treated as interchangeable almost everywhere and they are not. The practical move is the same either way: read what your agreement actually says about the code, and fix it now if it says nothing.

"Paying for a website does not answer every ownership question. Copyright, source access and the domain are separate rights, not one bundle.

Do website builders own your website?

Check the specific limits before you commit, because they differ sharply. Our breakdowns of what Webflow does and does not export, Squarespace's structural limits and what a Wix export actually contains each set out the real boundary for that platform.

Eight things to control or document

Ownership is specific or it is nothing. Four categories have to be named rather than assumed: the custom deliverables themselves, the domain registration and its recovery path, the hosting and infrastructure accounts, and every business service the site depends on. The test is simple: can you sign in, can you pay the bill, and can you remove anyone including us?

• ✓
  Client materials: content, data, brand assets, trademarks, photography, product records, and anything supplied by the client.
• ✓
  Agency background materials: reusable tools, templates, methods, libraries, know-how, and pre-existing code that are not sold as exclusive custom work.
• ✓
  Third-party materials: packages, fonts, images, themes, APIs, services, and other components whose original licenses and vendor terms continue to apply.
• ✓
  Operational knowledge: build instructions, deployment steps, diagrams, vendor list, account map, support contacts, recovery process, and known limitations.

Where the site sits on a hosted platform, the third-party column above is larger than it looks, because the platform itself is one of the components. Our comparisons of Wix, Squarespace, Webflow, Shopify and WooCommerce against a custom build each set out what stays with the platform in that arrangement.

Source code access is not the same as unlimited ownership

Receiving a repository is useful, but it does not erase third-party licenses or automatically transfer an agency's pre-existing framework. Conversely, a client can receive a broad, practical right to use, modify, host, and change providers even when some reusable components remain licensed rather than assigned.

Ask the agreement to answer: Which branch and history are delivered? Are build and deployment instructions included? Are there private packages? What secrets are excluded from source control? Can another developer operate the project? Which assets have use limits? What happens to incomplete or unpaid work? These details matter more than a bare promise of "full code."

Account control needs an operating plan

Client-controlled accounts are usually the cleanest exit path, but they still require role-based access, MFA, billing ownership, recovery contacts, and offboarding. Giving everyone the owner password is not control; it is a security problem.

• ✓
  Use company-controlled email addresses for account ownership and recovery where practical.
• ✓
  Give the agency the least privilege needed through individual roles, not a shared owner login.
• ✓
  Record who pays each vendor and who receives renewal, usage, security, and incident notices.
• ✓
  Store recovery codes and break-glass access in an approved password manager.
• ✓
  Define how access is removed, credentials rotate, logs are retained, and data is exported when the engagement ends.
• ✓
  Test that the client can deploy, restore, edit content, change DNS, and contact vendors before final handover.

Those tests are also what makes a future move possible. Our migration cost assessment covers the work involved in changing providers, and our article on what happens to search visibility during a migration covers the part of the handover that has to be monitored afterwards.

Five ways lock-in actually happens

Each control above fails in a recognizable way. Naming the failure modes makes them easier to write out of an agreement before work starts.

• ✓
  Domain: the registrar account is held in the developer's name, so transfer, DNS changes and renewal all depend on their cooperation.
• ✓
  Hosting: the live environment sits in an account the client cannot sign into, so the working site cannot be moved, restored or handed to anyone else.
• ✓
  Source: the client has a live site but no repository, build instructions or environment configuration, so changing provider means rebuilding rather than continuing.
• ✓
  Editing: content sits in a proprietary system, so text and images can be exported while the working site cannot.
• ✓
  Backup copies: where a provider retains a copy of delivered code, the terms should say whether it is held as recovery insurance for the client, for how long, and on what request process.

None of these requires bad intent at the start. They follow from an agreement that never allocated the control, which is why the remedy is written terms and a tested handover rather than a dispute afterwards.

What PandaCodeGen intends to put in the project terms

PandaCodeGen's public position is contract-first. The client keeps its content, data, brand assets, and client-controlled accounts. Rights in paid custom deliverables and repository transfer are defined in the accepted terms, normally after full payment. PandaCodeGen retains reusable internal tools, templates, methods, and pre-existing code. Embedded third-party components retain their original licenses.

When agreed, the client can control the domain, hosting, repository, and business accounts. PandaCodeGen can also manage services for the client when that is the preferred operating model. The SOW should name the account owner, billing owner, access roles, handover event, data export, and exit process. The phrase “no lock-in” is meaningful only when those controls have been tested. The test of a delivery arrangement is not whether you would leave it. It is whether you could.

Our custom engineering service page describes the delivery and handover process behind those terms, our engagement tiers show where support and handover sit in a package, and our delivered project write-ups show the arrangement in practice.

Refunds and incomplete work need separate language

The owner-approved refund intent permits repayment of the full amount when PandaCodeGen fails to deliver the signed contractual scope under the agreement's acceptance and remedy process. It is not an unconditional change-of-mind promise. The contract should state the refundable amount, cancellation treatment, approval process, timing, and what happens to work in progress.

The client keeps its own content and materials. Unpaid or incomplete project code does not automatically transfer merely because a refund occurs; the accepted terms must say what is returned, deleted, retained, or licensed. An approved refund is subject to the public processing window of up to 10 to 12 business days.

One question to ask before you sign

The full list below belongs in the statement of work. If only one question fits into an early conversation, use this one and ask for the answer in writing:

A provider that already works this way answers directly and puts it in the scope. Vagueness, or a preference for holding the domain or hosting "to keep things simple", is the point to slow down and ask for specifics. Ownership terms are easiest to settle while both sides are happy with the engagement.

Questions to put in the SOW before onboarding

Eight questions belong in the statement of work before any work starts, because after launch they become negotiations. What counts as a custom deliverable and when its rights transfer, what agency material is excluded and under what license, which third-party components carry their own terms, who controls each account, what is handed over, and what happens on nonpayment or termination.

• ✓
  What exactly is a custom deliverable, and when do its rights transfer?
• ✓
  What pre-existing agency materials remain excluded, and what license does the client receive to embedded items?
• ✓
  Which third-party components and services are used, under which licenses and current costs?
• ✓
  Who controls the domain, DNS, hosting, repository, CMS, data stores, email, analytics, commerce, CRM, and advertising accounts?
• ✓
  What credentials, documentation, exports, and training are delivered at handover?
• ✓
  What happens after nonpayment, termination, refund, or a material scope change?
• ✓
  What support period applies, when does it start, and what work is excluded?
• ✓
  What confidentiality, data-processing, backup, deletion, and security duties survive the engagement?

Our breakdown of what a Scale statement of work can include shows how these answers appear in a written scope. When you are comparing providers on those answers, our notes on what a low quoted rate leaves out and how to assess a development agency cover the same ground from the buying side.

Primary legal references

• U.S. Copyright Office Circular 1: Copyright Basics
• U.S. Copyright Office Circular 30: Works Made for Hire
• 17 U.S.C. 101: definitions, including work made for hire
• 17 U.S.C. 204: execution of copyright transfers

This guide is general information for a U.S.-first audience. Copyright, contract, employment, consumer, data, domain, and conflict-of-law questions can change by jurisdiction and facts. Use qualified legal counsel for the actual agreement.