# Handing off an app

> Give a finished app to a client: the three ownership shapes, what moves, and the handoff checklist.

You built an app for someone else, and now it needs to become theirs: their billing, their control, their responsibility. This page covers the shapes a handoff can take and what actually changes hands in each.

## Decide what "theirs" means first

Three arrangements cover almost every freelancer and agency situation:

- **They own it, you build in it.** The client has the workspace (and the plan); you join as an editor and build there from day one. Nothing ever needs to move, the client's card pays for the plan from the start, and ending the engagement is just removing your seat. This needs the client on [Teams](/docs/workspaces/roles-and-members), and it is the cleanest shape for ongoing work.
- **You own it, they watch.** You build in your own workspace and give the client a free viewer seat to follow progress. Right for fixed-scope projects, but plan the ending: the app still lives with you.
- **You own it, then it moves.** Build in your workspace, hand the finished project over at the end. Moving a project between workspaces is not self-serve yet; contact [support](/docs/reference/troubleshooting) and we transfer it. Everything travels together: code, database and its data, connected domain, and the published app.

## What the client needs on their side

- **A Vaulter account and a workspace**, on a plan that covers what the app uses. Paid features follow the owning workspace: if the app runs on a custom domain, requires sign-in to view, or uses [Pro extras](/docs/publish/publishing-extras), the destination plan must include them.
- **Their own connected services.** Connections like Stripe and Resend belong to whoever connected them. Handing off means the client connects their accounts, and the credentials you used for building get disconnected; plan a short overlap where you reconnect together.
- **The admin role in the app itself**, if the app has [admin pages](/docs/auth/add-sign-in): promote their account before you leave.

## The handoff checklist

1. Walk the client through the app on the published URL, not the preview.
2. Reconnect every third-party service to the client's own accounts.
3. Promote the client's account to admin in the app; demote or delete your test accounts.
4. Move the project (or your seat) to its final arrangement.
5. Hand over the domain's registrar account if the domain should be legally theirs, or confirm it was [bought in their Vaulter account](/docs/publish/buy-a-domain) to begin with.

## Frequently asked

#### Who pays for tokens while I build in the client's workspace?

The workspace pays: building in a client's Teams workspace spends their pool, which is usually the right arrangement and worth stating in your proposal either way. The owner can put a [budget](/docs/workspaces/budgets-and-audit) on your seat, which keeps that conversation easy.

#### Can I keep a copy of what I built?

Ask the client; the work belongs to whoever owns the workspace it lives in. With their blessing, [export the code](/docs/your-app/github-and-export) before the handoff, or save the project as a template in your own workspace for reuse of the structure.

#### The client is not technical. What is the minimum they must learn?

Three things: the App Users list (their customer door), the analytics page, and how to ask the agent for small changes. The [tutorials](/docs/tutorials/booking-app) make a good first week.