Playbooks / SaaS handover checklist
Playbook
SaaS handover checklist: how to sell or transfer a product
Selling a micro-SaaS means handing over more than code. The buyer needs every account, domain, key and subscription the product runs on, and you need to stop holding access you no longer should. This checklist covers both, in the right order.
Most handovers go wrong in the same way. The seller sends a zip file and a list of logins, the buyer starts using them, and months later the seller's old API key is still live, the domain is still registered to the seller's personal email, and a payment account still pays out to the seller. A clean handover takes a few days of careful work, not a few hours.
Before you start
- Agree what is being sold. The code, the domain, the customer list, the brand, the social accounts, the support inbox. Write it down in the sale agreement, so the inventory below has a clear edge.
- Check what's shared. If one cloud account, email domain or payment account also serves another of your products, it can't simply be handed over. Plan to give the buyer a separate account and migrate.
- Decide the cut-over date. Pick the day the buyer becomes the owner. Everything below is done around that day, and the seller's access ends on it, not before.
The steps
- Inventory everything the product uses. List every service, account, key, domain, subscription and certificate behind it: hosting, database, payments, email, auth, analytics, monitoring, AI APIs, app stores, code repositories, CI. For each one, record who owns the account, which email it is registered to and where its keys are used. Check billing statements and your inbox for anything you forgot.
- Sort each item: transfer or re-issue. Some things can change owner: a team or organisation account, a code repository, a domain. Some can't, or shouldn't: personal accounts, and often payment accounts, which are tied to the identity and bank details of whoever opened them. For those, the buyer opens their own account and you migrate the product onto it. Check each provider's own documentation before promising a transfer.
- Add the buyer as an owner or admin. Invite the buyer to every team or organisation account, using an email address they control. Do this first, while you still have full access, so nothing depends on a back-and-forth after you have lost it.
- Move ownership. Transfer repositories, organisations, domains and any account that supports it. For a domain, that means unlocking it and giving the buyer the registrar's transfer code, or moving it between accounts at the same registrar. Where an account can't transfer, the buyer sets up a new one and you move data, deploy settings and webhooks across.
- Rotate every key, token and secret you held. Anything you ever saw is still in your notes, shell history, password manager and backups. The buyer creates new keys in their own accounts, updates the deployments, and you revoke the old ones, following the key rotation playbook. Include database passwords, webhook secrets, OAuth client secrets and signing keys.
- Hand over the document and walk through it. Give the buyer the handover document (see the checklist below), then do one live walkthrough where they log in to every item themselves. Anything they can't open yet is a gap to fix now.
- Remove yourself. Once the buyer has confirmed access and the new keys work in production, remove your user from every team, change the contact email on anything still under your address, and cancel subscriptions that were billed to you. Keep a record of what you removed and when.
- Keep a short support window. Agree a period, such as 30 days, when you answer questions. Do not keep standing access for it: if you need to look at something, the buyer shares their screen.
Handover document checklist
One document, handed over in a secure way (never by email, and with secret values left out of it). It should list:
- Every account: provider, what it is used for, the owner, the registered email, the plan, the billing contact and whether two-factor sign-in is on.
- Every domain: registrar, expiry date, auto-renew status, and where DNS is hosted.
- Every key and secret, by name only: where it is used, what it can do, when it was created and by whom, and when it was replaced.
- Subscriptions and costs: each recurring charge, its renewal date and which card pays for it.
- Deployment: how the product is built and released, the environments, scheduled jobs and who gets alerts.
- Customers and data: where customer data lives, backups, and anything you promised users about it.
- Known problems: open bugs, expiring things and anything you were about to fix.
Common traps
The account is registered to your personal email. Whoever controls that mailbox can reset the password and take the account back. Move the contact email to an address the buyer controls before you remove yourself, and check every provider, your registrar included.
- Two-factor on your phone. If sign-in codes go to your phone, the buyer is locked out the day you leave, or you can still get back in. Have the buyer enrol their own second factor and remove yours.
- Keys created under your user. Some providers tie an API key or token to the person who made it, so it can stop working when that user is removed. Have the buyer issue replacements from their own user before you leave. Check each provider's documentation for how its keys behave.
- Payments that don't move. Don't assume a payment account can change owner. Check the provider's documentation, and plan for the buyer's own account, with customer and subscription data migrated through the provider's supported route.
- Forgotten copies. Old laptops, CI settings, shared notes, chat history and teammates' machines. This is why the keys are rotated rather than just handed over. If you find one pasted somewhere public, treat it as a leaked key.
- The sale falls through. If the deal collapses halfway, you will have invited a stranger into your accounts. Rotate again and remove them, then decide whether to keep running the product or shut it down.
Provider details
Each service has its own rules for ownership, keys and transfers. The provider pages list where each credential is created and what it does, for example Stripe, Vercel, GitHub, Supabase and OpenAI. For domains, see your registrar's page, such as Namecheap, GoDaddy or Cloudflare. For app stores, see Apple Developer and Google Play. Whether an account can be transferred, and how, is each provider's call: read their current documentation before you promise anything to a buyer.
Do this in StackHangar
Step 1 is the part StackHangar already does. Your vault groups every key, login, domain and subscription by project, and shows the account that owns each key, so the inventory for a sale is already written, and it stays in sync as you work. Because everything is encrypted on your device, you can export the inventory without the server ever seeing your secrets.
- Today: the per-project inventory, the account behind each item, expiry dates and email reminders, and the Rotate, Leaked key and Sunset playbooks, which are free.
- Coming: a guided Hand off playbook on the Studio plan. It is planned to walk you through transferring each provider account, rotating everything you held and producing the handover document. It is not available yet.