AppReadyLab
Ask a questionCheck my setup
DecisionsGuidesTested setupsLabMethodologyAsk a questionNewsletterCheck my setup
Operating guides/G02

Ownership playbook

Hand over an app so the client can operate without the original builder.

Who this is for

Agencies, freelancers, internal builders, and clients completing delivery or preparing for a future change of operator.

Definition of done

The client controls the business assets, can reach support and billing, and has evidence that another authorised operator can recover and maintain the service.

Before you start

Protect the current working path.

  • Agree what “handover complete” means and who accepts it.
  • Use named accounts; do not transfer a personal password by email.
  • List ongoing paid services and renewal dates before changing ownership.
  • Schedule access removal only after the client has tested their own administrator path.
01

Step 01

Create an ownership register

Make every business asset and dependency visible before access starts changing.

  • Domain and DNS
  • Hosting or application platform
  • Code repository and deployment
  • Database, identity, and file storage
  • Email and external integrations
  • Analytics, monitoring, invoices, and support contacts
02

Step 02

Establish client-owned administrator and billing access

The client needs an independent path that does not depend on the builder’s personal identity or payment method.

  • Invite named client administrators
  • Enable appropriate multi-factor authentication
  • Move billing and renewal notices
  • Record services that cannot transfer and the chosen replacement or contractual arrangement
Stop condition

Do not remove the current operator while the client still depends on that operator to sign in, pay, or contact support.

03

Step 03

Deliver usable code, data, files, and configuration

Ownership is practical only when assets can be used outside the original builder’s account.

  • Provide the production code version and build instructions
  • Export data with schema or field notes
  • Copy files with a reconciliation count
  • Document required configuration without exposing secrets in general documentation
  • List licences and non-transferable components
04

Step 04

Prove recovery and routine operation

A handover document is incomplete if the new operator cannot perform the tasks that keep the service usable.

  • Run a non-destructive restore rehearsal
  • Show where incidents and usage alerts appear
  • Perform one routine update or deployment
  • Verify a critical end-user path
  • Identify the provider, builder, and client responsibility for common failures
05

Step 05

Rotate credentials and remove unnecessary access

End shared access cleanly after the client has demonstrated control.

  • Rotate deploy keys, API keys, and integration secrets
  • Remove former users and personal recovery addresses
  • Verify automated jobs after rotation
  • Retain only explicitly contracted support access with an owner and expiry
06

Step 06

Sign off known limits and next actions

The final record should distinguish accepted operation from unresolved work or future improvements.

  • Record current plan, renewal dates, and expected costs
  • List unverified recovery or performance items
  • Name the first support contact and escalation path
  • Set the date for the next ownership and access review

Acceptance record

Do not close the old path until these statements are true.

  • The client can sign in, pay, contact support, and change authorised users without the original builder.
  • All production components appear in the ownership register.
  • A second authorised operator can follow the recovery and deployment notes.
  • Former access has been removed or retained under an explicit support agreement.

Help improve this decision

Did this answer your question?