Process Handover
Architecture document. Operational runbooks. Inline code documentation. Up to three walkthrough sessions. A 30-day warranty window. The handover is part of the project, not a separate transaction.
The handover is where most agency projects fail. The code ships, the contract closes, the customer team inherits a system they did not build and cannot operate. The six steps below are how we make sure that does not happen.
The six steps
Documentation written during the project, not at the end. Walkthrough sessions before the contract closes. A warranty window after, so your team has air cover while they take ownership.
01
Written overview of the system as built. Components, data flow, integrations, deployment pipeline, third-party services, environment variables. Diagram where helpful. Lives in your repo as ARCHITECTURE.md.
New engineers onboard from one document.
02
Operational procedures for the things that happen post-launch. Deploy, rollback, hotfix, scaling, monitoring alerts, common debug paths. One runbook per scenario, all in your repo.
Operations team knows what to do at 2am.
03
PHPDoc, JSDoc, or TSDoc on every public API. Hooks documented with examples. Custom block attributes documented. Database schema documented. The code reads like documentation, not just runs like documentation.
Future maintainers understand intent, not just behavior.
04
Up to three live walkthrough sessions with your team. We screenshare, walk the code, answer questions, demonstrate the runbooks. Recorded for stakeholders who could not attend.
Team has the context they need on day one of operating it.
05
For 30 days after handover, we answer questions and fix bugs in the work we shipped at no additional charge. Your team uses the system in production, asks questions, surfaces issues, we fix them.
No "you handed off, you are done" cliff.
06
For teams that want continued engineering support after handover, we offer a monthly retainer transition. Same engineers, same Slack channel, defined hours per month. Easy to start, easy to stop.
Continuity available, never required.
ARCHITECTURE.md covers the system as built. README.md covers local development setup. Runbooks cover operational procedures (deploy, rollback, monitor, hotfix). Inline PHPDoc, JSDoc, or TSDoc covers the code itself. CHANGELOG.md tracks releases. CONTRIBUTING.md covers how to make changes safely.
Documentation lives in the repository, version controlled with the code. Not in a separate Confluence space that drifts out of date.
First session covers the architecture and the data flow. Second session covers operational procedures, runbooks, and monitoring. Third session covers code-level walkthrough of the most important modules. All sessions are recorded, all are interactive, all are scheduled before the contract closes.
Bugs in the code we shipped, for 30 days after handover. Questions about how something works, for 30 days after handover. Updates to documentation based on what your team finds confusing, for 30 days after handover.
The warranty window does not cover new features, scope changes, or changes to systems we did not build. Those go through a new fixed-price project or a retainer.
Three options. Your team operates the system independently with no ongoing relationship to us. You buy another fixed-price project for specific updates as you need them. You move to a monthly retainer for ongoing engineering capacity. All three are normal. We have happy customers in each path.
Common questions
Documentation includes operator-level runbooks (no code required) for common operational tasks: deploy, rollback, monitor. For deeper changes, you would need an engineering team or a retainer with us. We are honest about that during discovery.
Yes. The repository is yours from day one. We work in your GitHub or your GitLab or your Bitbucket. We do not retain any private copy of your source. License rights are spelled out in the contract.
Credentials live in your secret manager (1Password, AWS Secrets Manager, Vault, Doppler, your choice). We never have a private copy. At handover we revoke our access to production. You can audit access logs after.
Documentation is written incrementally during the project, not at the end. The architecture doc and runbooks are reviewed in the final sprint. Walkthrough sessions happen in the final week. Total handover time is typically one sprint.
Two options. Buy another fixed-price project for the specific updates. Or move to a monthly retainer for ongoing capacity. Both options are documented and quoted on request.
Want a real handover that does not abandon your team?
Documentation, walkthroughs, and warranty are part of every project. Discovery call is free.
