The handover problem no one talks about at launch
The scenario is familiar, and it plays out months after a project closes. A build was completed. The client accepted delivery and paid the invoice. Then something needs to change — a hosting configuration, a deployment credential, an environment variable. The client reaches out to the original team. The team has moved on. Nobody can find the credentials. The client cannot access their own infrastructure. This is not an unusual edge case. It is the predictable result of a handover process that treated delivery as a file transfer rather than an ownership transfer.
What a complete handover actually transfers
A complete handover has four components. The production deliverables per the signed scope of work — this is what most teams treat as the whole handover, when it is actually just the first component. The access transfer documentation: credentials, platform accounts, DNS records, deployment configurations, all documented with confirmed client receipt before the engagement closes. The technical documentation: the Software Bill of Materials recording every dependency at delivery, the environment variable list, the deployment procedure. And the post-launch support terms, scoped as a maintenance retainer — not an informal promise that becomes a source of conflict when support is needed.
Documentation is not for the person who built it
Technical documentation is not a record for the developer who built the system. It is a record for whoever operates or maintains the system next — whether that is a future agency, an internal team, or the client themselves. The Software Bill of Materials records the dependency inventory at the moment of delivery: every package, its version, its license. The environment variable list documents every configuration value the system requires to run. The deployment procedure documents how a new version is released without institutional knowledge of the build. Without these three documents, operational continuity depends on a phone call to a person who may not be available. That is not a handover. It is a dependency.
What project close-out actually requires
Every NoDrftSystems project close-out follows a defined sequence before anything transfers. Quality sign-off must be on file: all review categories complete, with human authorization confirmed in writing — not assumed from verbal acceptance. Legal review is logged for any contract, IP assignment, or regulatory element in the deliverable. A sweep of the handoff package confirms that no internal proprietary assets — governance documents, system architecture, internal methodologies — are present in what the client receives. Every access credential, platform account, DNS record, and deployment configuration is documented with confirmed client receipt before the engagement closes. Founder authorization is required before any package transfers: this is a direct sign-off, not a delegation, and it does not happen until every prior step is complete. The package is assembled last — containing only what the signed scope of work promises, reviewed before it leaves. No timeline pressure justifies skipping or compressing this sequence. A step skipped to meet a delivery deadline becomes a defect that surfaces after the deadline has passed — at which point the cost of correction includes not just the technical fix but the trust required to ask the client to accept a second handover.