What every client should receive at the end of every project - the one-folder deliverable that ends vendor lock-in, builds ferocious trust, and takes an afternoon to systematize
For agencies, studios, and freelancers who build things clients keep: websites, platforms, tools, campaigns, systems. Somewhere right now, a business owner is discovering that their website's hosting is registered to an agency that no longer answers email, their domain renewal is billed to a card belonging to a contractor from 2019, and nobody - literally nobody - knows the CMS admin password. This playbook is about being the vendor after whom that story is impossible. It costs you almost nothing. It is worth more than most portfolios.
Start with the scale of the problem, because every builder has met it from the receiving side. Take on any new client with an existing digital footprint and the first week is archaeology: Who controls the domain? Where does DNS actually point? Is there hosting access, or just a monthly invoice from a mystery LLC? Which plugins are licensed to whom? Where's the source code - and is the thing running in production even the same code? The previous vendor didn't necessarily do bad work. They just left the way almost everyone leaves: deliverable shipped, invoice paid, knowledge dispersed. The client didn't notice anything missing - until the day they needed to change vendors, fix an emergency, or simply renew a domain, and discovered they'd never actually possessed the thing they paid for. They'd possessed access to a vendor who possessed it.
Now the uncomfortable half of the diagnosis: some vendors leave it this way on purpose. Opaque handovers are a retention strategy - the client who can't leave, doesn't - and everyone in the industry knows a shop whose stickiness is 40% relationship and 60% hostage situation. Which is exactly why doing the opposite, visibly and systematically, is not just ethics; it's positioning. The vendor who makes leaving easy is the vendor clients don't leave - the same paradox as every other trust structure: dependence repels, and demonstrated freedom binds. A complete handover pack says, in artifact form, "we intend to be chosen again, not needed again" - and clients can feel the difference between those two sentences in their spine.
The pack itself is one folder, five sections, mostly assembled from things that already exist. The discipline is completeness and the ritual around it.
Section 1: The access map - the crown jewels page
One document listing every system the project touches and who holds the keys: domain registrar (account owner, renewal date, auto-renew status, which card), DNS (where it's managed - often not the registrar, often the surprise), hosting (provider, account owner, plan, billing), the platform/CMS admin, databases, email services, analytics properties, third-party services and their API keys' locations (never the keys themselves in this document - the pack points to the client's password manager or a properly shared vault, it doesn't become the vulnerability), payment providers, and any licenses (themes, plugins, fonts, stock) with what's licensed to whom and what expires when.
Two rules make this page the pack's heart. Everything in the client's name. Domain registered to the client. Hosting on the client's account (you retain collaborator access). Licenses purchased under their identity or explicitly transferred. "It's easier if we hold it" is how every hostage situation in this industry begins, always with good intentions; the handover pack's first principle is that convenience-custody ends at delivery. And the renewal calendar stated plainly: the three dates per year that, missed, take the business offline - domain, hosting, critical licenses - listed with costs, so no renewal ever depends on a vendor's memory or a mystery invoice's continued arrival.
Section 2: The technical dossier - enough for the next competent person
Written for a reader who is technical but wasn't there: what the system is (stack, architecture in a paragraph and a simple diagram, hosting shape), where the source code lives (client-accessible repository - their org or a transferred copy; production deployed from that code, verified, because a repo that drifted from production is a false comfort), how to deploy (the honest steps, even if the honest steps are humble), the integrations and what breaks if each one does, and the known debts - the corners cut with reasons, the "we'd fix this next" list. That last item feels like self-incrimination and reads as its opposite: every system has debts, and the vendor who documents theirs is the vendor whose other claims get believed.
The completeness test for this section is concrete: could a competent successor take over in a day instead of a forensic week? Write to that reader. You may be that reader, three years from now, when the client returns.
Section 3: The operator's guide - for the humans who run it
The non-technical half: how to do the ten things the client's own team will actually do - update content, add a product, pull the report, change a price, add a user - each as a short numbered recipe with screenshots, in the order of how often they'll need it. Plus the triage page: what to try first when something looks wrong, what's an emergency versus an annoyance, and who to contact for which class of problem. If a usage video exists (a fifteen-minute screen recording covering the top five tasks costs nothing and outperforms most manuals), it lives here.
This is also where your support boundary gets its written form - the launch-support window, what bug-fixing covers, what's billable after - stated once more, calmly, in the same folder as everything else, so the post-launch relationship starts on the agreed physics rather than on assumptions.
Section 4: The decisions record - why it is the way it is
One page most handovers never include and every future vendor (including future-you) blesses: the five to ten significant decisions and their reasons. Why this platform over that one. Why the checkout works this way. Why the integration was built custom instead of using the obvious plugin - and what the obvious plugin would have broken. Decisions without recorded reasons get relitigated by every successor, usually expensively, occasionally catastrophically ("we removed that weird redirect" - the weird redirect that held the SEO together). Ten minutes per project while memory is fresh; hours of someone's future archaeology, deleted.
Section 5: The handover ritual - delivery is a meeting, not a folder link
The pack lands in a thirty-minute closing session, not an email attachment: walk the access map together and verify live that the client can actually log in to the crown jewels (the difference between having credentials and having tested credentials is the difference between insurance and a rumor of insurance); flag the renewal calendar; tour the operator's guide's top three recipes; and state the support boundary once, warmly. Then the sentence that does the positioning work, said out loud: "Everything here means you're never dependent on us - you own all of it, and anyone competent could take over tomorrow. We'd obviously rather it stays us." Clients remember that sentence. They repeat it to other founders. It is, word for word, the referral pitch you didn't have to make.
Systematizing it, briefly: the pack is a template folder cloned per project, its sections filled progressively during delivery rather than excavated at the end (the access map starts at kickoff - it's the same information onboarding should have gathered anyway; the decisions record accretes one line per big call), and its completion is a named checklist item before the final invoice. Total marginal cost once templated: an hour or two per project. Total differentiation: ask anyone who's inherited the other kind of handover.
The whole pack on one page
One folder, five sections, delivered in a ritual. The access map: every system, every key-holder, everything in the client's name, renewal dates stated - custody ends at delivery. The technical dossier: stack, code in the client's hands and verified against production, deployment honestly described, debts admitted - written so a competent successor needs a day, not a forensic week. The operator's guide: the ten real tasks as recipes, the triage page, the support boundary in writing. The decisions record: what was chosen, what was rejected, and why - so nothing load-bearing gets relitigated blind. And the closing session: credentials tested live, renewals flagged, and the sentence said out loud - you own everything, anyone could take over, we'd rather it stays us. The vendors who fear this folder are confessing their retention strategy. The vendors who ship it get the only retention that compounds: clients who stay because leaving was always allowed.