Free template
The handover standard for every development project. Free.
This is the exact handover documentation template we enforce on every project delivered through our platform. No sign-up, no email gate. Copy it, use it with your own developers, and never inherit a black box again.
Eight sections. If a developer cannot produce all eight, the project is not finished — it is abandoned in instalments.
1. Tech stack and versions
- Languages, frameworks, and exact versions (e.g. Node 20.11, React 19, PostgreSQL 16)
- Package manager and lockfile location
- Infrastructure services and their plan tiers
- Anything pinned, forked, or patched — and why
Why this section exists: Versions drift silently. A new developer needs the exact picture on day one, not a guess.
2. Deployment steps
- Which services run the app: hosting, CDN, queue, storage
- Build commands and the environment used to build
- Release steps, in order, written so a second person can follow them cold
- Rollback procedure when a release goes wrong
Why this section exists: If only one person can deploy, the project is one resignation away from downtime.
3. Environment variables
- Every variable name and what it does
- Which environments need it (development / staging / production)
- Where the values are stored — values live in a secret manager, never in this document
Why this section exists: Missing environment variables are the number one reason a fresh clone refuses to start.
4. Third-party services
- Service name and what it is used for
- Which account — and which email — owns it
- Renewal date and billing method
- Where DNS is managed and how to change it
Why this section exists: Accounts lapse silently. Renewal dates and ownership prevent surprise outages.
5. Admin access and test accounts
- URL of every admin panel and back office
- A test account for each role (credentials live in the password manager, not here)
- How to reset an admin password
Why this section exists: Verifying admin access is the first thing any new developer must do — before touching code.
6. Database schema and backups
- Schema diagram or migration files location
- Backup schedule and where backups are stored
- How to restore from a backup — tested, not assumed
Why this section exists: A backup that has never been restored is a hope, not a backup.
7. Cron jobs and scheduled tasks
- Every scheduled job: name, schedule, and what it does
- What happens if it fails silently
- Where its logs go
Why this section exists: Silent cron failures corrupt data for weeks before anyone notices.
8. Known limits and workarounds
- Known bugs and limitations, listed honestly
- Temporary workarounds currently running in production
- What breaks first under ten times the load
Why this section exists: Honest limitations let the next developer prioritise instead of discover.
Every project on our platform hands this over — enforced, not optional.
That is why we can take over projects other developers abandon: the standard exists, and we hold every developer to it. Use this template with your next hire, or post your project where it is already the rule.