What Code Handover Means for Firms
Website source-code handover means that, once the build is finished, the developer transfers the full program to the client, covering the public interface, the admin system, and the database structure. The client receives a permanent right to use it, may change it, and may hire another team to maintain it. Later work does not have to stay with the original developer: edits, hosting moves, and future maintenance can be handled freely. Few custom-build teams treat a complete code package as a standard deliverable and write that promise into the contract.
Many owners assume that anything they paid for automatically belongs to them. In practice, most web studios do not volunteer the code, and contracts often avoid the subject on purpose.
The sections below explain what a handover should include, why many vendors hold code back, what it costs to go without it, and how contract terms can protect the client.
What a Full Handover Includes
Many owners picture “source code” as a handful of loose files. Clients often say they already have materials, yet the folder contains only design mockups and front-end pages. A genuinely complete handover should include at least the following:
| Item | Description | Why it matters |
|---|---|---|
| Front-end code | HTML, CSS, and JavaScript that shape look and interaction | This is everything visitors see |
| Back-end code | PHP, Python, Node.js, or similar, forming the admin core | Content updates and orders depend on it |
| Database structure | Tables, migration scripts, and seed data | Content, customers, and orders live here |
| Technical notes | Environment needs, deploy steps, and API notes | Another engineer can take over only with this |
| Design sources | Figma or Photoshop files, if they were produced | Later redesigns need not start from zero |
Delivery versus No Delivery
| Aspect | Code received | Code not received |
|---|---|---|
| Ownership | Fully belongs to the client | Effectively remains with the vendor |
| Changing maintainers | Leave anytime with the code | Often forced to negotiate, sometimes at a premium |
| Vendor shutdown | The site can keep running | The site may disappear with the vendor |
| Moving hosts | Move to any host | Tied to the vendor host and hard to leave |
| Adding features | Any engineer can modify it | Only the original vendor, with little room to bargain |
| Annual maintenance | Renewal is optional | Not renewing may mean losing the site |
| Long-term cost | Controlled by the client | Decided by the vendor |
| Digital asset | Can gain value over time | Can drop to zero at any moment |
Why Many Studios Withhold Code
Frankly, this is usually not a technical limit. It is a choice of business model.
Lock-in as a Revenue Model
The most common reason is simple: once a client has the code, they can maintain it themselves or hire someone else, and the vendor may lose the yearly maintenance fee.
A studio that refuses handover is effectively saying: “You did not buy the site outright. You are renting it. The technology stays with us, and you must pay each year to keep using it.”
That arrangement favors the developer and puts the client at a severe disadvantage. In plain terms, the site remains someone else’s asset.
Fear of Code Being Copied
Some teams worry that code will leak or be copied. The concern is understandable, but the proper response is a confidentiality clause, not withholding work the client has already paid for.
Platform Licenses Block Handover
If a site is built on a commercial WordPress theme, Wix, Squarespace, or a similar platform, the core code belongs to the platform. The studio structurally cannot hand over the entire source. That is one fundamental difference between templates and custom builds.
Weak Engineering Makes Handover Hard
Some small studios or freelancers do not manage versions carefully. After the files are handed over, even the original author may be unable to run them again. That signals engineering quality, and it is why a client should ask to see a past delivery checklist before signing, to judge whether a real process exists.
Five Risks of Missing Code
The situations below come up repeatedly in practice (names omitted). Owners most often fall into these traps:
Vendor Failure Takes the Site
A trading company once spent 300,000 on a custom site. Three years later the design studio closed, and the site vanished with its data. Without a code backup, the company had to rebuild from scratch and spent another 250,000.
If the code had been in hand: moving the files to a new host would usually cost a few thousand and take about a day.
Non-renewal Means Going Offline
One company paid maintenance fees for years and discovered the lock-in only when it tried to switch. The original vendor said that ending the contract would take the site offline. The site sat on the vendor’s server, the code had never been transferred, and the client had almost no leverage.
If the code had been in hand: end the relationship politely and leave with the program.
Add-ons Get Inflated Quotes
A client once wanted one simple feature. The original vendor quoted far above the market. Outside engineers estimated much less, but without the code they could not take the job. The client had to accept the high price.
If the code had been in hand: compare several quotes and choose a fair one.
Stuck on Outdated Technology
Some vendors rely on a closed system they built themselves. As technology moves on, that system grows obsolete, yet the client cannot leave: either keep enduring it or pay heavily to rebuild. Before signing, ask which framework will be used so you are not locked into an obscure stack.
New Tools Cannot Be Integrated
Connecting a LINE official account, Google Analytics 4, an AI support tool, or a third-party payment service all requires going back to the original vendor for a quote when you lack the code. A closed system may not connect at all. That constraint is especially costly while AI tools are multiplying.
How to Protect Yourself in Contract
Before signing a web-design contract, check at least these four clauses:
List Every Deliverable
The contract should itemize what must be handed over:
Preferable wording: "Party B shall hand over: (1) the complete site code (front end, back end, and database migrations); (2) technical documents and environment setup notes; (3) design source files (Figma/PSD)." Wording to avoid: "Party B delivers one website."Assign Intellectual Property
Preferable wording: "Copyright in this project passes to Party A once all fees are paid." Risky wording: "Copyright remains with Party B; Party A receives only a license to use."A right to use and ownership are very different. A license often means you may use the site but may not modify it, transfer it, or give it to someone else to maintain.
Set a Handover Deadline
A common arrangement is to transfer the code after acceptance and final payment. The contract should state a deadline, for example “within seven business days after acceptance.”
Specify the Handover Method
State whether delivery will be a Git repository, cloud storage, or a physical drive. A Git repository is preferable because it keeps a full version history and makes it easier to verify that the code is complete.
One Simple Test Question
When choosing a web-design partner, one question is enough:
“After the site is finished, will I receive the source code?”
If the answer is yes, have it written into the contract. If the other side hesitates, changes the subject, or says an extra fee is required, the business model is usually built on keeping the client, not on returning the finished work.
Teams that write “full source-code handover” into every contract are uncommon. It is not that others cannot do it. Some choose not to.
Work that has been paid for should belong to the client.
Further Reading
- How to read a custom-site quote: how the fee is built
- How to choose a local web studio: points to weigh before deciding
- Custom builds versus templates: strengths and limits of each
- Clauses to check before signing: key legal points
