Deliver a product to a client
Transfer code, accounts, and the knowledge needed to run and maintain the product.
Why this matters
Picture handover day. You step away, and the client must run the product, change it, recover when it breaks, and know who owns each part it depends on. That ability is what you are delivering — not just a repository. Plan this while you build; waiting until the final demo reveals the domain, database, or integration logins belong to the wrong person.
What to understand
Name the intended use: demonstration, limited pilot, or supported production. List what is real, what is simulated, and what is unverified. A working browser session does not prove saved data survives reload, or that another maintainer can deploy it. Tie each claim to a specific revision and environment.
Watch for
- Accounts, billing, or DNS still owned by you on handover day.
- Real secrets — passwords, API keys — sitting in the delivery notes.
- Documentation alone treated as authorization for changing access or sending credentials.
- "Technical debt" used to vague away a missing permission check or an unreliable save.
- Acceptance marked without the responsible person actually accepting.
Strong default
Transfer accounts and permissions through the client's approved process. Link authoritative files rather than copying them into a manual that will drift. For each open item, name the consequence, owner, and when to revisit it.
When this doesn't apply
A handover manual that copies every config file and command output is not thorough — it's a drift risk. Link the authoritative files; write down only what someone needs to run, recover, and know who owns what. A demo handover and a production handover carry different weight — match the package to the intended use.
In practice
Ask whether someone with the intended access can:
- Clone the repository and install from its lockfile — the file that pins exact versions.
- Configure required values from documented names and safe examples.
- Run the app and the relevant checks.
- Deploy a preview using the intended accounts.
- Complete the critical workflow and find a failed operation.
Check this path on a clean setup where you can, rather than trusting your own configured machine.
| Area | What the client needs |
|---|---|
| Repository | Access, branch and release rules, and the delivered revision. |
| Hosting and domains | Correct account ownership, billing, deployment and DNS access. |
| Data and storage | Access boundaries, retention, backup coverage, and restore steps. |
| Integrations | Account owner, setup, limits, and how to rotate credentials. |
| Monitoring | Where failures show up, who responds, and starter steps to follow. |
| Design system | Token and component sources and reasons for key conventions. |
Document the core workflow, architecture boundaries, commands, environments, deployment and undo path — undoing a release (saved data stays saved) — and known limits. Walk the client through the real experience, including one relevant recovery path. Record what you checked and what remains unverified. An application rollback — restoring the prior code — is different from restoring saved data or reversing side effects like sent emails.
Verify
Ask your agent to run $readiness for the final assessment and $context for repository guidance. For a new feature in an inherited product, $slice starts from existing contracts rather than replacing them.
Related skills
Use $readiness, $context, and $slice as above. Delivery is done when the client can run, change, and recover the product without you.
Last updated on