The Post‑Launch Handover Checklist Every Client Should Insist On
Most websites and apps don’t fail at launch - they fail three to six months later.
Not because the work was “bad”, but because the handover was incomplete: missing logins, unclear ownership, no monitoring, no backups, and thin documentation. The result is slower fixes, surprise costs, and accidental vendor lock‑in.
At Jensen Technologies, we’ve been running as a web development agency for many years, and we’ve seen one pattern repeatedly: a clean handover reduces risk more than almost any framework or library choice. Below is the checklist we recommend every client insist on after launch.
1) Ownership and access (non‑negotiable)
If you don’t control the accounts, you don’t control the product. Ask for a single document that lists every account involved and who owns it.
- Account inventory: domain registrar, DNS provider, hosting/cloud, CDN, email/SMS provider, analytics, tag manager, payment processor, CRM, helpdesk, app store accounts, and any automation tools.
- Admin access transferred to company-owned emails (not personal addresses).
- 2FA enabled with recovery methods documented.
- Ownership map: a simple table showing what is owned by you, what is owned by the agency, and what is owned by third parties.
Practical tip: if an account can’t be transferred, insist on documented shared access and a clear exit plan.
2) Source code and build artifacts
Even if you don’t plan to change vendor, you should be able to continue development tomorrow with another team if needed.
- Repository access (GitHub/GitLab/Bitbucket) or a full source export.
- Production version tagged (a release tag/commit hash that matches what’s live).
- Build and deploy instructions: how to build the project, how to deploy it, and how rollbacks work.
- Environment configuration explained: what is stored as secrets, where those secrets live, and how they’re updated.
3) Infrastructure and architecture documentation
You don’t need a 40-page document. You need enough clarity that a competent team can safely operate and extend the system.
- One-page architecture overview (including key services and dependencies).
- Hosting details: provider, region, and what services are used.
- Scaling assumptions: expected traffic, background jobs, rate limits, and current known constraints.
- Runbook for common incidents: site down, slow pages, failed payments, emails not sending, mobile build failing.
4) Monitoring, logging, and alerting
If you can’t see problems, you can’t fix them quickly. Monitoring is part of the deliverable.
- Uptime monitoring with alert thresholds and notification channels.
- Error tracking (front-end and back-end) with actionable alerts.
- Centralized logging: where logs live, who can access them, and the retention period.
- On-call expectations: who gets alerted, and the expected response time.
5) Backups and recovery (tested, not assumed)
Backups that have never been restored are a comforting story, not a plan.
- What is backed up: database, file uploads, object storage, configuration, and any third-party exports you rely on.
- Frequency and retention: daily, hourly, and how long data is kept.
- Restore process documented and tested: when was the last successful restore?
6) Security basics and data handling
You don’t need perfection, but you do need a baseline: clear responsibilities and repeatable practices.
- Dependency update plan: how security patches are applied and how often.
- Permissions review: least privilege for admins, CI/CD, and third-party services.
- Secrets management: where keys live, how they’re rotated, and who can access them.
- Privacy notes: what data is collected, why, and where it flows (especially important for GDPR).
7) Analytics and success measurement
Post-launch decisions should be based on evidence, not guesswork.
- Analytics ownership transferred (you should be the account owner, not just a user).
- Event/goals documentation: what is tracked and how to interpret it.
- Success metrics list tied to outcomes (leads, signups, purchases, retention), not just pageviews.
8) Training and operational documentation
Your team should be able to run the day-to-day without waiting for a developer.
- Admin training for the CMS/back office (ideally recorded).
- Short “how to” guides: editing pages, managing products, processing refunds, creating users, exporting data.
- Known limitations and recommended next improvements.
9) Warranty, support, and maintenance clarity
Confusion here is where budgets get blown and relationships get strained.
- Bug-fix window: what qualifies as a bug and how long it’s covered.
- Change request process: how new work is scoped, estimated, and approved.
- Maintenance options: what a monthly plan includes (updates, monitoring, small improvements, SLA).
How to use this checklist
If you’re about to launch, ask for this checklist before final sign-off. If you’ve already launched, it’s still worth doing a structured handover audit - it often pays for itself the first time something goes wrong.
If you’d like to discuss what a good handover looks like for your specific website or app, or you want help auditing your current setup, get in touch with Jensen Technologies. We’re happy to help you make your product easier to own, operate, and grow.