A web project ends twice. It ends when the site goes live, which everyone notices, and it ends when the handover is complete, which frequently never happens at all.
The gap between the two is where most long-term pain lives. The site works, the invoice is paid, everyone moves on — and eighteen months later you discover that nobody wrote down how to deploy it, the design files are in a personal account, and the only person who understands the payment integration has changed jobs.
Handover is not a formality at the end. It is a deliverable, and it should be specified in the quote alongside the pages and the functions. Here is the list to specify.
Work through it at the end of your next project. Fourteen items, four groups. If you cannot tick them all, the project is not finished, whatever the invoice says.
Group one: the accounts
These are the ones that determine whether you own the thing or merely use it. We covered the full argument in who owns your website — this is the version you check at handover.
1. Domain registration in your company's name, in an account you can log into, with auto-renew on and paid by your card.
2. DNS access, wherever the records live. This is the switchboard for the site and the mail, and it is the one people forget until a migration breaks email.
3. Hosting account in your name, or a written statement of what you are renting, from whom, at what price, and what the exit process is. Renting is fine. Renting without a documented exit is not.
4. The code repository in your organization, with full history, and your developer invited as a member rather than the other way around. History matters: a repository with one commit called "initial" is a copy, not a handover.
5. Administrator accounts on the CMS or admin panel, on analytics, on the payment gateway, and on any third-party service the site depends on. Administrator, not editor.
Group two: the working knowledge
This is the group that separates a real handover from a pile of files. All four items are short documents. None of them takes a day to write, and their absence costs months.
6. How to run it locally. The commands to get the project running on a new machine, and what has to be installed first. If a new developer cannot get it running in an afternoon, your supplier market has one participant in it.
7. How to deploy a change. The single most valuable page in the entire handover. What command, what pipeline, what checks, what to do if it fails.
We took on WClinic, a Saint Petersburg clinic network, where this document did not exist and could not be reconstructed from anyone's memory. The legacy site had no documented way to deploy it at all. Before a single feature, the environment had to be restored, containerized and moved to Git with CI. That is what a missing one-page document costs when the person who knew leaves.
8. Where the configuration lives, and what each value does. Environment variables, API keys, feature flags. Not the secrets themselves in a document — a list of what exists, what it is for, and where the real values are stored.
9. The external dependency list. Every third-party service the site calls, what it does, whose account it is under, and what it costs. Payment provider, mail sender, maps, search, analytics, SMS. Each one is a renewal, a price rise and a possible outage that you should not be discovering for the first time during the outage.
Group three: the assets
10. Editable design files, not exported images. Figma files you can open, with the components intact. Without these, the first change to a color or a layout starts by recreating work you already bought.
11. The design system or style definitions — the tokens, the type scale, the spacing, the component rules. This is what lets a different designer make a new page that looks like it belongs.
12. Image sources at full resolution, plus a note on licences. If stock photography was used, you need to know which licence covers what, because "we used a photo we found" is a liability that surfaces at the worst possible time.
Group four: the proof it works
13. A test suite you can run, and its result. You do not have to read the tests. You should be able to run one command and see them pass.
This is not a nicety. On Knigopoisk there are 171 tests with 898 assertions, run in parallel — and one of them fails if an admin table column ships without a label, which is a very specific piece of institutional memory encoded so that nobody has to remember it. On BiliMind there are 164 backend tests. Those numbers are not there to impress anyone; they are there so a change made two years from now, by someone else, does not quietly break checkout.
14. A short "known issues and deliberate limits" note. What does not work, what was descoped, what is fragile, what would need attention if traffic grew tenfold.
This is the item suppliers hate writing and buyers value most. A handover that claims everything is perfect is a handover that has not been honest with you, because nothing is. We publish limits on our own work for the same reason — our AI receptionist is described on the site as a browser demo only, with the production voice flag off and no telephony leg, because a capability you cannot use is not a capability, and pretending otherwise is a debt someone pays later.
Run the handover before final payment, not after
The sequencing here matters more than the list.
Our payment terms are 50% to start, 50% when it is live and you are happy — which puts the final payment after launch by design. That is the natural moment to run this checklist, and the reason is practical rather than adversarial: a handover checked while the project is still live in everyone's mind takes an afternoon. The same checklist run six months later is an archaeology project.
The best way to check items 6 and 7 is not to read them. Ask a different developer to follow them. An hour of an independent pair of hands attempting to run and deploy your project will tell you more than any document review. If they succeed, you have a real handover. If they cannot, you have discovered a single-supplier dependency while you still have a supplier.
The one-page version
Print this and use it as the agenda for the handover call.
| # | Item | Ticked |
|---|---|---|
| 1 | Domain in our name, auto-renew on | |
| 2 | DNS access | |
| 3 | Hosting account or written exit terms | |
| 4 | Repository in our organization, full history | |
| 5 | Administrator accounts on every service | |
| 6 | How to run it locally | |
| 7 | How to deploy a change | |
| 8 | Configuration list and where values live | |
| 9 | External dependencies, owners and costs | |
| 10 | Editable design files | |
| 11 | Design system / style definitions | |
| 12 | Image sources and licences | |
| 13 | Test suite, runnable, passing | |
| 14 | Known issues and deliberate limits |
Ask for it at quote stage, not at the end. A supplier who has this ready before the project starts is telling you something about how the project will end.
Why a supplier would want this
An obvious objection: handover is how a supplier makes themselves replaceable, so why would anyone do it well?
Because the alternative business — clients who stay because leaving is hard — is a bad business to be in. It fills your calendar with people who resent you, and it means every renewal conversation is really a negotiation about captivity.
We state it on the services page as a commitment: no lock-in, ever. After the included support period, maintenance is $39 a month or nothing. Take the code and go elsewhere. Staying is a monthly choice, not something we engineered you into needing.
That position only works if handover is genuinely complete, which is why it is a deliverable in the quote rather than a favor at the end.
Tell us what you need. You get a fixed price and a delivery date back — free, and with no obligation to proceed.
Frequently asked questions
My project is finished and I have none of this. What do I do?
Ask, politely and in writing, while the relationship is still good. Most suppliers will provide all of it — the absence is usually inattention, not intent. Do the account items first, since they are the ones with consequences you cannot reverse.
Is it reasonable to ask for documentation on a $99 landing page?
Proportionate documentation, yes. For a small site, items 1 to 5 and 10 are non-negotiable, and items 6 and 7 might be four lines in a README. The principle scales down; it does not disappear.
What if the developer says the code is their intellectual property?
Be precise about what is being claimed. A studio reusing its own internal libraries across clients is normal. Your site, your content, your configuration and your data are yours. Settle this in one sentence in the agreement before work starts, because settling it afterwards is slow and expensive.
Do I need the tests if I cannot read code?
You do not need to read them. You need them to exist and to run, because they are the mechanism that stops a future change from silently breaking something you rely on. Ask for the command and the output. That is enough.
How long should handover take?
For a small site, an hour on a call and a few documents. For a platform, a day or two, plus the independent-developer check. If a supplier needs weeks to produce it, the honest reading is that it is being written for the first time — which is itself useful information about the state of the project.
