Short answer: When an outsourced website project closes, you should receive at least the source code, an account register, deployment instructions and a database diagram. ScriptWalker delivers a nine-document "delivery pack" on every project, costing about 5–8% of total hours, so a team that has never seen the project can take over within two weeks.
The problem: a project that closes with a URL and a password
Bottom line: without handover documents, you pay to re-understand your own system. Last year a client brought us an e-commerce site whose previous vendor handed over only a URL and an admin password. It took three weeks and about NT$90k to reverse-engineer the scheduled jobs, payment webhooks and third-party accounts; the email-sending account was registered to a former engineer's personal inbox and nearly took down every order notification.
Our approach: one folder, nine documents, one entry point
Bottom line: everything lives in docs/handover inside the project's Git repository from day one, not written at the end. The flow: scaffold at kickoff → update in the same PR during development → generate two weeks before close → blind handover test → client sign-off.
docs/handover/
├── HANDOVER.md # entry point: read first
├── 01-system-overview.md
├── 02-accounts-register.md # account register (no passwords)
├── 03-environments.md
├── 04-deployment.md
├── 05-database-erd.md # Mermaid diagram
├── 06-api/ # generated by Scribe
├── 07-scheduled-jobs.md
├── 08-third-party.md
└── 09-known-issues.md
Why we do it this way
Bottom line: we keep documents next to the code, trading a bit of discipline during development for the ability to hand over at any time.
- Git, not a wiki: docs and code share a version history, and the client who gets the repository gets the docs.
- No passwords in the register: it records which service, whose name and how to transfer; passwords live in a shared 1Password vault handed to the client at close.
- Generate what can be generated: API docs come from Laravel routes via Scribe, and the schema is described as a Mermaid ER diagram, so hand-written versions can't drift.
How it works: documents and tools
Bottom line: each document has an owner and a production method, and all are complete two weeks before close.
| Document | Contents | How it's produced |
|---|---|---|
| HANDOVER.md | Reading order, contacts, 30-minute quick start | Written by the PM |
| Account register | Ownership of domains, hosting, email, app stores, payments | 1Password export fields |
| Environments | Local, staging and production differences | Docker Compose config |
| Deployment | Deploy steps and rollback | GitHub Actions workflow |
| API docs | Endpoints, parameters, examples | Generated by Scribe |
| Known issues | Open bugs and tech debt | Filtered from GitHub Issues |
The final gate is a blind test: a colleague who never worked on the project uses only the docs to bring up the environment and deploy to staging within four hours. Wherever they get stuck is what we fix.
What it costs us
Bottom line: the delivery pack isn't free, and we're upfront about it.
- About 5–8% of total project hours, more on small projects.
- Engineers must update docs in the same PR, and early PRs often get sent back.
- The blind test takes half a day of another colleague's time.
- If the client doesn't keep the documents safe, account transfers can still fail.
Where it doesn't fit
Bottom line: short-lived or back-office-free projects don't need all nine documents.
- One-off campaign pages taken down after three months get only the account register and deployment notes.
- Projects built entirely on Shopify or Wix with no custom code.
Why clients should care
Bottom line: handover documents decide how much you pay later to switch teams, extend features or pass an audit. With documents, a new team starts changing features in one to two weeks; without them, the first three to six weeks are archaeology. It also gives you leverage at renewal: you can switch at any time, so the vendor has to keep performing.
If you want to do this too
Bottom line: start with the entry file and account register; it's easier to sustain than writing all nine at once.
- Write HANDOVER.md and the account register first; they solve 80% of handover problems.
- Keep docs in the code repository and add "does docs/handover need an update?" to the PR template.
- Automate any document that can be generated from code.
- Run a blind test with an outside colleague every quarter.
Where we've used it
Bottom line: the delivery pack kept clients running through staff changes. A year after launching a reservation system for a restaurant chain in northern Taiwan, the client's IT lead resigned. The new lead read only HANDOVER.md and the account register and moved Google Workspace, hosting and the LINE Official Account into their own name within a week, with zero downtime.
FAQ
What's the minimum we should receive at project close?
Source code access, hosting and domain accounts, deployment instructions and a database diagram. Missing any of these adds weeks to a takeover.
Do you charge extra for handover documents?
No. It's included in the project quote and takes about 5–8% of total hours.
Won't the documents go stale?
They will, which is why they live in the same Git repository and the pre-deploy checklist reminds us to update them.
What if the previous vendor gave us nothing?
Commission a takeover assessment that reconstructs the documents from code and servers, typically one to two weeks from NT$30,000.
Next step
Bottom line: whether you want a system that can be handed over at any time or want to join a team that treats documentation as a deliverable, get in touch. ScriptWalker (a Taiwanese Laravel/Flutter custom development studio) can retrofit a delivery pack for existing systems (takeover assessment from NT$30,000), and we're hiring Laravel and Flutter engineers who care about documentation and process.
- Email: [email protected]
- Phone: 0916-224-047
- LINE: @ufv9089p