What website source-code handover means
Source-code handover means that, once a site is finished, the builder transfers every program file and related asset to the client, who then holds full rights to use them.
What you pay for should belong to the party that paid. In the web-design market, however, firms that actually follow through on this are still uncommon.
What a complete handover covers
A complete handover is more than a handful of page files. It includes every asset the site needs to run:
- Front-end code: HTML, CSS, JavaScript, and all responsive layout styles
- Back-end code: server-side business logic, API interfaces, and data-processing flows
- Database structure: table design, relationships, and setup scripts
- Design assets: sliced graphics, icons, and licensed images
- Deployment documents: install notes, environment settings, and third-party service keys
Missing any item means the handover is not truly complete. People often say they already have the files, then find only front-end HTML. That is like buying a car with no engine: it looks whole, but it cannot run.
Handover, license, and open source
These three ideas are often mixed together, yet they mean different things:
| Concept | What you receive | Can others use it | Can you change it |
|---|---|---|---|
| Source-code handover | Full code plus permanent use rights | No, only you hold it | Yes, with full freedom |
| License to use only | No visible code, use only | No | No, only the original vendor can |
| Open-source software | Publicly available code | Anyone may use it | Yes, under the license terms |
Handing code to you is not the same as open-sourcing it. The programs are built for your business, and you are the sole rights holder. That is entirely different from open-source software such as WordPress or Linux, which anyone may download and use.
To see how custom design and templates change what you finally receive, read how custom sites differ from template sites.
Why most design firms withhold source code
Few firms treat a full source-code handover as a core offer. Three reasons usually explain the refusal:
Reason 1: annual hosting fees
Many studios quote a low build fee to win the job, then collect yearly hosting charges. Those fees often run from a few thousand to tens of thousands, and a multi-year lock-in becomes a sizable sum.
If you receive the source code, you can rent a server and host the site yourself, and that revenue disappears. Withholding the code is therefore usually a business tactic, not a technical limit: if you cannot leave, billing can continue.
Reason 2: fear of lost renewals
Smaller studios often worry that after months of work, the client will take the code and hire someone cheaper to maintain it.
The concern is understandable, but holding the code hostage is the wrong fix. A healthier approach is to earn renewals through service quality rather than technical lock-in. Teams that hand over the full code often see steadier repeat business, because good service is the strongest way to keep clients.
Reason 3: platforms that cannot export code
Some firms build client sites on SaaS platforms such as Wix, Squarespace, or Shopify. The code runs on the platform's own servers, so the builder never obtains it and cannot hand it over.
That is not entirely the vendor's fault; the platform is designed that way. If your site lives on such a platform, what you own is often only an account. Price changes must be accepted, and if the platform shuts down, the site vanishes. That is a very different kind of security from actually holding the source code.
Firms that deliver versus those that do not
| Trait | Firms that hand over code | Firms that withhold code |
|---|---|---|
| Build method | Custom development | Templates or a SaaS platform |
| Hosting policy | Client may choose any host | A designated host is required |
| Fee structure | Maintenance fees are clear and optional | Annual fees are locked in; nonpayment takes the site offline |
| Freedom to revise | Anyone qualified can take over | Only the original vendor can change it |
| Client relationship | Retention through service quality | Retention through technical lock-in |
Three real risks of never receiving the code
The three situations below show up repeatedly in long-running project work. Details are anonymized, but the events are real, and owners most often fall into these traps.
Risk 1: the vendor closes and the site vanishes
A manufacturing client paid well over a hundred thousand several years ago for a company site. It was hosted on the vendor's server, and the source code was never delivered. The studio later shut down quietly, with no notice and no transfer, and the site simply disappeared from the web.
When the client sought help, only a few old design screenshots remained. Years of product data, search rankings, and browsing history were gone. Rebuilding cost about one and a half times the original fee.
If the source code had been in hand, moving the files to a new host could have restored the site in less than a day.
Risk 2: revisions quoted at extreme prices
One company wanted new features after using its site for years, and the original vendor's quote far exceeded expectations. Other firms were asked to estimate the work, but without the source code they could not judge the effort and would not take the job.
That is classic technical lock-in: the feature itself is not worth that price; only the original vendor can do it, so there is no room to negotiate. Similar cases are not rare in practice.
Risk 3: forced yearly hosting payments
A more common case is a client paying about twenty-four thousand a year for managed hosting. After four years the total nears one hundred thousand, almost enough to rebuild a simple company site. Moving to a self-rented server to cut costs is impossible without the source code.
People who ask for help share one trait: the contract never stated who owned the source code.
A responsible practice: full handover
One simple principle should be kept: once the client has paid, the client should receive everything.
A healthy business earns money from build fees and the quality of maintenance, not from locking clients in by withholding code. Teams that operate this way usually give every client the complete programs, with no exceptions.
Checklist due after acceptance
After a project is accepted, the client should receive:
- Complete front-end and back-end code, neither encrypted nor obfuscated
- Database structure and a data export
- Original design files, including sliced graphics and icons
- Deployment notes covering environment needs and install steps
- Third-party accounts and keys, such as payments and messaging
- Admin accounts and an operations manual
What you can do once you have the code
- Move freely: host the site with any provider, without the original vendor's approval
- Revise freely: hire any capable engineer or firm to maintain and extend it
- Back up freely: keep a full copy so an accident does not wipe the site
- Extend freely: compare several providers before deciding who builds a new feature
That is what it means for the site to be yours. For the path from planning to launch, see a full guide to setting up a website.
How to confirm code ownership before signing
Whichever web-design firm you choose, confirm source-code ownership in writing before you sign. Use the checks below.
Three clauses every contract needs
- Scope of delivery: list the items (code, database, assets, documents). Do not stop at the words deliver the website.
- Copyright and use rights: state who owns the copyright and what rights the client holds (permanent, exclusive, and whether they may be sublicensed).
- Timing and method: state how many days after acceptance the files arrive, and how (drive, cloud, or repository).
Sound contract language versus weak language
| Clause | Clear wording | Problematic wording |
|---|---|---|
| Delivery scope | All source code, including front end, back end, database, and design assets, is delivered within seven days of acceptance | The finished website is delivered, with no list of what that includes |
| Copyright | Copyright stays with the builder; the client holds a permanent, irrevocable right to use the work | Copyright is never mentioned, so it defaults to the design firm |
| Hosting freedom | The client may deploy the site on a hosting environment of their own choice | The site must be hosted on a server designated by the builder |
A transparent contract confirms the delivery list, copyright ownership, and scope of use item by item before signing. It leaves no gray area and hides no clause.
If you are comparing web-design firms, put the source-code handover policy first. A company unwilling to promise this basic point in writing gives reason to doubt its other promises.
Copyright needs a separate explanation
One distinction matters: handing over source code is not the same as assigning copyright.
A common and responsible arrangement is that the builder keeps the copyright while the client holds a permanent right to use the work. The client may use all code and design results indefinitely, including changes, extensions, and hosting moves, without extra limits, but may not resell the source code to a third party or sell it as a product.
This is a reasonable industry practice. The builder keeps copyright to protect methods and architecture built up over time. The client's permanent use right protects freedom to operate. The two do not conflict, much as an architect may retain copyright in the drawings while the owner may live in, renovate, or even sublet the building.
Closing: three points to remember
If only three points from this article stay with you, keep these:
First, no source code means technical lock-in. No matter how attractive the pitch, without the programs you lose control of your own site. Switching firms, moving hosts, or adding features all depend on someone else's goodwill.
Second, put it in writing before you sign. Do not rely on verbal promises. The contract should state delivery scope, copyright ownership, and delivery timing. If those clauses are missing, do not sign.
Third, the handover promise belongs in every contract. Delivering the full source code should not be a last-minute slogan. It should be an operating rule from the first day of the engagement.
