How we work
What a proper software handover actually contains
'You own the code' means nothing without the keys, the docs, and the knowledge. The exact contents of our handover pack. Use it as a checklist on any vendor.
Alphacroft · 18 May 2026 · 6 min read
Vendor lock-in is rarely a contract clause. It's an accumulation of small omissions: the deploy process that lives in one person's head, the domain registered under the agency's account, the admin password nobody wrote down. Each is trivial; together they mean you can't leave.
Our handover pack is designed against that accumulation. Here's the full contents, publicly, so it functions as a checklist you can hold any vendor to, including us.
The pack, itemized
Ownership transfers: the code repository moved to your organization's account (not shared, transferred), domain and DNS control, cloud accounts in your name with billing you control, every third-party service (email, payments, analytics) owned by an address you control.
Credentials: a complete inventory in a proper password manager export, every login, every API key, every signing certificate, with notes on what each one touches and how to rotate it.
Documentation: an architecture overview a new engineer can orient from in an afternoon; a runbook covering deploys, rollbacks, backups and their restore procedure (tested, with timings); and a decision log (why Postgres, why this queue, why not the obvious alternative), because the whys are what the next team actually needs.
Knowledge: a recorded handover session walking your team (or your next vendor) through the system, plus 90 days of included warranty for anything that turns out to have been missed.
The test
The standard we hold the pack to: a competent engineer who has never met us should be able to deploy a change to production within a day, using only what's in the pack. If they'd need to email us, the pack is incomplete.
Ask your current vendor when you could run that test. The answer is informative either way.