Should the client own the codebase? Yes, and the handover is where that becomes true: the GitHub repository, the hosting project, the domain and every provider account move into the client’s name, and every key is reissued from those accounts. How to hand over an app to a client is that transfer, with a test the client runs per item.
This is the agency’s seat in production hardening: the point where running the app stops being your job. What the word delivered should mean, the five checks behind it, which accounts the agency opened and has to move or recreate, and what to settle before the last invoice, including whether you keep access, are all set out in what delivering an AI-built app to a client means. This page is the transfer itself, one asset at a time, with each vendor’s own path and what that path leaves behind. If you are the founder receiving the app, the question to start with is owning an app someone else built.
How to hand over an app to a client: what the client should end up holding
After a handover the client holds, in their own name, the repository, the hosting project, the database, the domain and every provider account, and every key has been reissued from those accounts. The test for each is the same: someone at the client signs in as owner and can remove the agency.
When a client wants access to source code, or asks whether the client should own the codebase, my answer is yes for the code written for them, and the contract is what decides it. On agency clients and code ownership, common practice as I read it splits along one line: the client owns the delivered code, and the agency keeps the reusable tooling it brought to the job; that is a reading, not law. A source code ownership agreement example is a contract clause that writes that split down, so this page describes it and drafts none, and none of this is legal advice. Who owns the source code, and the accounts an owner checks, is covered in the nine things that have to be in your name.
What you hand over with a website or an app comes down to the rows below: one per asset, how it moves by the vendor’s own path, what that path leaves behind, and the test the client runs. The mechanics come from GitHub’s repository transfer docs, Vercel’s project transfer docs and Supabase’s project transfer docs, read on 27 September 2026.
| Asset | How it moves (the vendor’s own path) | What does not move with it | The client’s test |
|---|---|---|---|
| Repository (GitHub) | GitHub’s repository transfer: issues, pull requests, wiki, stars and watchers go across; webhooks, services, secrets and deploy keys “will remain associated after the transfer is complete”; Git information about commits is preserved | Not one list in GitHub’s docs. It names a few: “we don’t redirect GitHub Pages associated with the repository”, and a move from an organization to a personal account leaves read-only collaborators behind. Anything the agency doesn’t remove first, old secrets and commit history included, goes across (the reason for checklist item 6) | Signed in as owner, the client lists the collaborators. GitHub adds the original owner as a collaborator on the transferred repository, and that seat is the client’s to remove or keep for a period agreed in writing |
| Hosting project (Vercel) | Vercel’s project transfer: an owner of the team it leaves, who is a member of the team it joins, moves it; deployments, environment variables (except those set in the env and build.env configurations of vercel.json), domains and the Git repository link go across | Integrations (added again afterwards), log data and monitoring data; for a subdomain, the root domain stays on the origin scope | The client triggers a deploy from their own team |
| Database (Supabase as the worked example) | Supabase’s transfer between organizations: the owner of the source organization moves it, and must be at least a member of the target; its conditions include “No active GitHub integration connection” and “No log drains configured” | Not stated as a list in Supabase’s docs; usage up to the transfer stays billed to the source organization | The client signs in to their organization and sees the project there, and on a paid plan the invoice in their name |
| Domain | The registrant on the record and the registrar login move to the client; a move between registrars follows ICANN’s Transfer Policy | DNS hosted somewhere else stays where it is (my reading: the registrar and the DNS host are separate services) | The client signs in to the registrar and reads the records |
| Payment account (Stripe) | Stripe’s owner transfer: the current owner can hand ownership to a user who holds the Administrator or Super Administrator role | A change to the business the account is registered to: a separate step, which Stripe’s page on a business sale or acquisition says starts by contacting Stripe Support | The client holds the Account Owner role |
| App store record (Apple) | Apple’s app transfer between developer accounts, started by the Account Holder (the iOS section below) | The Apple Pay merchant ID; the sender’s App Analytics access | The app shows in the client’s App Store Connect account |
Two GitHub conditions are worth knowing before you start. A transfer to another personal account expires “If the new owner doesn’t accept the transfer within one day”, and “If you transfer a private repository to a GitHub Free user or organization account, the repository will lose access to features like protected branches and GitHub Pages”. On Vercel, a target team with no valid payment method has to add one before the transfer. A client app that earns money belongs on a paid team, in my reading of Vercel’s Hobby page, which says the plan “restricts users to non-commercial, personal use only”. For payments, Stripe’s owner transfer changes which user owns the account, not the business it is registered to. For that, Stripe’s page on moving an account to a different entity after a business sale or acquisition says to contact Stripe Support first to confirm which details change, and a buyer in another country follows a different process. Where the client’s business should hold the account and that route doesn’t fit, it is opened fresh in the client’s name and reconnected; the delivering article linked above makes that point about payment accounts.
In the Production Hardening Sprint, this is deliverable 2.8, provider account ownership: every service the product depends on (database, hosting, payments, email, AI, domain) moves into an account the founder owns, with the founder as the owner role, billing in the founder’s name, and any previous builder removed. Deliverable 2.8 is verified this way: produce an inventory listing each provider, the owning account, the owner role holder, and the date the previous builder’s access was removed.
The client handover checklist
The agency client handover template I’d use is this list plus the table above, and it serves a freelance client handoff the same way. Client handover checklist software is not needed, because a shared checklist and a signed document do the job. The code cleanup checklist before handover comes first, since a stranger is about to read the code, and how to clean up a vibe-coded app sets its order. Items 1 to 5 settle code ownership at handover and items 6 to 12 prove the app runs without the agency, so one checklist covers both halves. The whole-product proof, a change going live from the client’s own account, sits with the other four delivery checks in the delivering article linked above; the items here are the per-asset steps those checks presume, each with its own evidence. If you hand over a website to a client rather than an app, the same list applies, with the builder route in the first subsection below.
- 01 Repository transferred to the client. Test: the client, as owner, lists who has access and removes the agency, or records the agreed end date of its access. Evidence: the repository access list, dated.
- 02 Hosting project transferred. Test: a deploy started by the client, from the client team, goes live. Evidence: the deploy id and its date in the client team.
- 03 Database and storage in the client organization. Test: the client signs in and sees the project under their organization, and on a paid plan its invoice. Evidence: a screenshot of the organization page, taken by the client.
- 04 Domain in the client name. The registrant on the record is the client and the registrar login is theirs. Test: the client signs in and reads the DNS records. Evidence: the registrar record page.
- 05 Every other provider account owned by the client. Payments, email, AI and error tracking, with the agency access that remains either removed or written down with its agreed end date. Test: the client lists the members of each. Evidence: the provider inventory.
- 06 Every key reissued from the client accounts, and the old one revoked. Test: the client rotates one key alone, following the runbook, and the app keeps working; once the old key expires, a call made with it is refused. Evidence: the rotation record.
- 07 The environment inventory. Which variable lives in which environment. Test: a fresh environment is built from it. Evidence: the inventory, dated.
- 08 The documentation set. Test: a developer who has never seen the app follows the setup section. Evidence: their notes.
- 09 Runbooks for deploy, rollback and restore. Test: the person at the client who will run them does the rollback once. Evidence: the dated run.
- 10 A recorded walkthrough. Test: the recording plays and names every account in the ownership table. Evidence: the file and its date.
- 11 The pre-launch security review. Test and evidence: as the next section sets out.
- 12 Support terms in writing. What the agency fixes after handover, for how long, through which channel, from which date. Test: the client can find the dates in the handover document. Evidence: the signed page.
Item 5’s inventory is the one described in the provider inventory a founder should hold, and item 7’s follows separate variables, databases and keys. Item 8 is also the answer to what documentation is required at handover, and the set itself is laid out in documentation for a vibe-coded app.
Item 6 is a separate line because the repository moves with its commit information intact, and three of the 21 third-party apps I audited had a real secret permanently in git history: a webhook signing secret, a live AI-provider key, and a Stripe test key with its webhook secret. Those 21 apps came from my June and July 2026 audits, a selected set rather than a random sample, so the count is no rate for AI-built apps in general. Timing matters as well. A Stripe key rotated in the Dashboard does not die at once: Stripe’s API keys page says “both the old and new keys work for up to 7 days”, and “If you choose Now, the old key is deleted”. So the agency’s copy of a rotated key stops working only when the expiry you picked passes, and after that Stripe answers a request carrying it with an authentication error. The safe order is in how to rotate API keys safely.
Item 9 follows a runbook template, and item 10 is a live session; how to run a technical handover session is its own subject. Item 12’s terms come from the post-launch support checklist; what the agency still answers for beyond those terms is the last section of the delivering article.
The sprint has its own versions of items 9, 10 and 12, each with a check. Deliverable 13.3, operating runbooks, is verified this way: walk through the runbooks against the delivered configuration and reference the rehearsal evidence. For the live technical handover, deliverable 13.4, the check is to deliver the recording, supporting documents, and answers or follow-ups from the session. Deliverable 13.5, fourteen-day defect cover, is verified this way: record the coverage dates, reporting channel, reproduction details, fixes, and retest results. Deliverable 13.7, thirty-day async access, is verified this way: provide the channel, access instructions, and the start and end dates in the handover.
A static site or a builder-hosted app
How to give a client their website on a builder is that builder’s own transfer feature: Wix Studio and Framer each publish a transfer page, and those pages rank for this search. For Base44 and Lovable projects, what moves and who may move it is each builder’s own documentation, and I don’t restate it here. After the builder’s feature, items 4, 5 and 12 cover what sits outside the builder. An agency that built in its own Lovable workspace has to give the website to the client from there, and what moves at the end of client work on Lovable covers that route. The delivering article reads two builders’ transfer pages in detail.
A Next.js or full-stack project
Handing over a Next.js project to a client leans on items 1, 2, 6 and 7. Vercel carries the project’s environment variables into the client’s team (the hosting row above has the one exception), so in my reading every key the agency issued keeps working after the move, which is exactly why item 6 exists. The integrations have to be connected again once the move completes.
Take an agency that transfers the GitHub repository and the Vercel project to the client’s team, after which the client deploys from their own account. The environment variables came across with the project, so the app still runs on keys issued from provider accounts the agency opened, and the repository’s history still holds whatever was ever committed to it. The transfer moved the project, not the accounts behind its keys. The lesson I take from it: the handover is finished when the client has reissued those keys from accounts the client owns.
An iOS app
To hand over an iOS app to a client, Apple moves it between developer accounts with an app transfer that “Your membership Account Holder initiates”, and the receiving Account Holder accepts. The app keeps its reviews and ratings, its Bundle ID stays with it, and its App ID goes to the recipient’s developer account. Among Apple’s transfer criteria, “The app must have at least one version that was released to the App Store”, and both parties “must have accepted the latest version of their paid and free agreements”. An app that was never released can’t be transferred, so in my reading it is set up in the client’s own account instead. Before the transfer, TestFlight beta testing should be turned off and all Xcode Cloud data must be removed; after it, “the merchant ID isn’t transferred along with the app”, and the sender loses access to the app’s data in App Analytics. Apple also leaves the code to the two of you: “The transferor is responsible for exchanging the actual code set and building assets directly with the recipient.” The full list is in Apple’s app transfer overview. Whose name the developer account should be in is whose name goes on the Apple developer account. Items 1, 5 and 6 then apply as they would to any app.
The security review the client will be asked about
An app security review before client launch checks who can read whose data, which secrets sit in the code or its git history, which dependencies carry published advisories, and whether payment webhooks check their signatures. The handover document then records what was checked, what was not, and the date.
Run it as a list with a test per line, the application security checklist, and keep the evidence the way the handover items keep theirs. A tick with no evidence behind it is a claim the client can’t defend when their own customer asks, so every line gets a result someone can re-read.
In my reading, a customer’s security questionnaire can ask who reviewed the code and when, and the handover document is where the agency’s answer lives. The questionnaire itself is a separate subject: the security questionnaire. For checklist item 11, the test is that the client can open the record and name, for each check, what was tested and on which date; the evidence is that dated record.
If the client’s customer or investor wants an independent review, what one covers is its own question, the web application security audit, and buying one means a code audit service or source code review services. For a builder-made app, the build tool’s own checks are not the review; what the tool covers and what is still yours is in whether vibe-coded apps are safe.
What a good handover document looks like: an agency client handover sample
A good handover document runs to about two pages in my working rule: what the client now owns and where, the checklist results with dates, the issues left open, the support terms, and two signatures. It is the file I would give a new developer, or a buyer’s reviewer, before anything else.
| Section of the document | What goes in it | Who signs or checks it |
|---|---|---|
| What the client owns, and where | The ownership table, one row per asset, with the date each one moved | The client, by signing in to each account |
| Checklist results | Each item with its test, its evidence and the date it passed | The person at the client who ran the test |
| Access removed | Who lost access, to what, and when; any access kept, with its agreed end date | The agency lists it; the client confirms it |
| Known issues left open | Each issue with the person who owns it | Both sides |
| Support terms | What is covered, for how long, through which channel, and the start and end dates | Both sides |
| Where things live | Links to the documentation, the runbooks and the recording | The client, by opening each link |
| Signatures | One from the agency, one from the client, dated | Both sides |
Filled in, that table is the client handover document itself. This sample is the agency’s version; the client handover document template in generic form, for any software project, is the software project handover checklist. Below is an example of a handover document for one small SaaS, constructed for this page rather than taken from a client: a Next.js app on Vercel with a Supabase database, a Stripe account and a domain held at a registrar.
| Section | The constructed example |
|---|---|
| What the client owns, and where | Repository in the client’s GitHub organization; Vercel project in the client’s team; Supabase project in the client’s organization; Stripe account with the client as Account Owner; domain registered to the client at their registrar; each dated the handover date |
| Checklist results | Twelve lines, each with its test, its evidence file and its date |
| Access removed | Agency logins removed from Vercel, Supabase and Stripe on the handover date; the agency’s GitHub collaborator seat kept to the end of the support period, with that date written in |
| Known issues left open | One open issue, owned by the client’s developer, with a note of where it is tracked |
| Support terms | Fixes for defects in the delivered work, through one named channel, with a start date and an end date |
| Where things live | Documentation and runbooks in the repository’s docs folder; the recording in the client’s shared drive |
| Signatures | The agency lead and the client’s owner, dated the handover date |
If the kept GitHub seat sits on a repository owned by a personal account rather than an organization, it can’t be read-only: GitHub says “collaborators can’t have read-only access to repositories owned by a personal account”. What the agency sends when the work goes across, and why every line should already be tested by someone outside the agency, is answered in the delivering article’s questions. There is nothing to download here: copy the table, and that is the template.
What it costs and how long it takes
Handing an app over is mostly agency time: about a day for the transfers and the key reissue in my working rule, plus any cleanup first. Vercel states a project transfer may take between 10 seconds and 10 minutes, depending on the associated data, and a transfer the losing registrar leaves unanswered for five calendar days is approved by default.
| Step | Fee, as the vendor states it | Time, as the vendor states it |
|---|---|---|
| Repository (GitHub) | Not stated in GitHub’s docs | Not stated in GitHub’s docs |
| Hosting project (Vercel) | None stated for the move; the target team needs a valid payment method first | The range stated above, with zero downtime |
| Database (Supabase) | None stated for the move; usage is billed to the source organization up to the transfer and to the target after it | Not stated, except that a move from a paid to a Free Plan “might come with a short 1-2 minute downtime” |
| Domain | The registrar’s own price; not stated by ICANN | Default approval after five calendar days with no answer; a 60-day inter-registrar lock after a change of registrant, unless the registrant opted out beforehand where the registrar allows it |
| App (Apple) | Not stated in Apple’s docs | The recipient must accept within 60 days of the request; after that, “It can take up to two business days for the app transfer to complete” |
Both domain timings are close to the words of ICANN’s Transfer Policy, sections I.A.3.5 and II.C.2, in the version updated on 21 February 2024, which contracted parties may implement from 21 August 2024 and must implement no later than 21 August 2025. The lock is why order matters when a domain changes both registrar and registrant: change the registrant first and, unless the opt-out was taken before that request, the domain can’t leave its registrar until that lock runs out. A Supabase move onto the Free Plan also checks the two free project limit, so upgrade the client’s organization first if they already have two.
Any cleanup the code needs before a stranger reads it comes on top of that day, and what a vibe coding cleanup costs breaks it down.
Where the sprint fits
Whether a white label engineering partner is the right arrangement, and who owns the code such a partner writes, is covered in what a white-label partnership is. What an agency checks before a partner touches client work is in white label development partner checks.
The Production Hardening Sprint ends in a handover of its own. That handover delivers the updated codebase, tests and deployment configuration, a readiness report and technical due diligence pack, instructions for releases, backups, recovery and incident response, guidance and automated checks for future AI-assisted changes, and a recorded handover. Post-handover support is 14 calendar days of fixes for defects in the delivered sprint work and 30 calendar days of async access for questions about the handover and architecture. Third-party hosting, service subscriptions and API consumption remain in the client’s own accounts , and new product capabilities sit outside the sprint. Every deliverable and the check behind it is in the published scope.
Common questions about handing an app over to a client
How do I handover a website to a client?
Move the repository or the builder project, the hosting, the domain and every provider account into the client’s name, then reissue the keys from the client’s own accounts. A site made on a builder moves with that builder’s transfer feature instead of a repository transfer, and the domain and any outside accounts still move on their own.
What is the recommended format for a handover?
A short document holding the ownership table, the checklist results with dates, the open issues, the support terms and two signatures, backed by the runbooks and a recorded walkthrough. Keep the document short enough that the client reads all of it, and let the runbooks and the recording carry the detail.
How to prepare a handover checklist?
Start from what the client must own, one line per asset, then add a test the client can run for each line and the evidence to keep once it passes. A line the client can’t test without the agency is a promise, not a checklist item.
How do I create a handover document?
Fill in the seven sections of the document table above, date every result, and have both sides sign. Write it after the checklist has been run, so each line reports a test that already passed rather than one that is planned.
If you have a working app built with these tools and need it ready for real customers, this is what we do.
Built it with AI. Now it has to hold up for real customers.
The Production Hardening Sprint takes the app you already have and builds the production foundation underneath it. Authentication and access rules, payments that stay consistent, error handling, monitoring, backups, automated tests and a documented handover. Our engineers work inside your existing codebase for ten working days. All 123 deliverables are included, and you get the evidence for each one.
See the Production Hardening Sprint → 
$2,500 fixed price · 10 working days · One codebase