App Handoff Checklist: What Founders Must Receive at Launch

Why the handoff matters more than launch day

Launch day feels like the finish line. But the handoff is what decides whether you control your app. None of the problems below is technical. Each one comes down to who holds the keys. Fixing it at handoff takes a few hours. Fixing it a year later, after the agency has moved on, can take weeks. Here are three situations founders run into:

• An investor asks for technical due diligence, and the repository sits in the developer's personal account.
• You want a new developer to add a feature, and nobody wrote down how to run the app.
• The App Store listing is under the agency's developer account, so you can't publish an update without them.

1. Code: a GitHub repository in your name

The code should live in a GitHub organisation that your company owns, and you should be the owner or admin. A link to someone else's repository isn't enough. Neither is a zip file. How to check it yourself:

• Log in to GitHub and open the repository from your own account.
• Look for your role in the settings. It should say Owner or Admin.
• Look at the commit history. You should see weeks of work, not one single upload. That history shows how the app was built.

2. App store accounts: Apple and Google under your company

For a mobile app, you need an Apple Developer account and a Google Play Console account in your company's name. The app should be published from those accounts. Open the accounts early, because Apple and Google verify the business before you can publish. Then add your developer as a team member. That way they can submit builds while you keep ownership. Moving an app from someone else's account to yours later is extra work you can avoid.

3. Hosting, database and domain

Your app runs on several services: hosting for the web app or backend, a database, file storage and a domain name. Each one should be billed to your company and logged in with your email. Ask for a list of every service, then check each one:

• Can you log in?
• Is the billing on your card?
• Are you listed as the owner, not only a member?

4. Third-party services and keys

Most apps connect to outside services: payments, email sending, push notifications, analytics, maps. Each one gives the app secret keys so it can talk to that service. At handoff you need to know which services are used, which account each key belongs to, and how to change a key if someone leaves. The keys should belong to accounts in your name. Ask for them through a password manager or another secure channel, never in a plain email or chat message.

5. A list of dependencies

Every app is built on top of libraries written by other people. A dependency list names them, so a future developer or an investor's tech reviewer knows what is inside your product and what needs updating. You don't need to read it. You just need to have it, along with the licence of each library. If questions about licences or who owns which part of the code come up later, start with this list. Have a lawyer handle legal questions about licences or IP terms.

6. Documentation another developer can follow

The test for good documentation is simple: could a developer who has never seen your app get it running from the documents alone? At a minimum, the handoff documentation should cover:

• How to run the app on a computer.
• How to deploy a new version of the web app, and how to send a new build to the stores.
• Where each piece runs, and which services it connects to.
• What was left out of this version and why.

7. A walkthrough and a support window

Ask for a short recorded walkthrough of the app and its admin side. It costs the developer an hour and saves you many. Then agree on what happens after launch. Bugs will show up once real users arrive. You want to know who fixes them, for how long, and how you report them. Halfway through and unsure what your current developer is handing you? Book a call. Bring your list and we'll go through it with you.

The checklist at a glance

Print this, or copy it into a doc, and tick each line before the final payment.

• Code. What "done" looks like: GitHub repository in your company's organisation, you as owner. How you check it: open it from your own login, check your role.
• Commit history. What "done" looks like: full history of the build. How you check it: scroll the commits list.
• Apple Developer account. What "done" looks like: company account, app published from it. How you check it: log in to App Store Connect.
• Google Play Console. What "done" looks like: company account, app published from it. How you check it: log in to Play Console.
• Hosting and database. What "done" looks like: billed to you, you as owner. How you check it: log in to each service.
• Domain. What "done" looks like: registered to your company. How you check it: log in to the registrar.
• Third-party services. What "done" looks like: listed, in your name, keys shared securely. How you check it: compare the list to your logins.
• Dependency list. What "done" looks like: libraries and their licences. How you check it: file in the repository or a shared doc.
• Documentation. What "done" looks like: run, deploy and architecture notes. How you check it: ask a developer friend to skim it.
• Walkthrough. What "done" looks like: recorded video of the app and admin side. How you check it: watch it once.
• Post-launch fixes. What "done" looks like: written period and process. How you check it: check your contract or proposal.

When to ask for each item

Don't wait until the last day. A good handoff starts on day one. If you started with an AI app builder, the first step is getting the code out of the builder and into your own repository. Our AI prototype to production page explains how we audit and harden prototypes like these. For what comes after delivery, see our post-launch guides.

• Before the build starts: create the GitHub organisation, the Apple and Google accounts and the hosting accounts in your company's name, then invite the developer.
• During the build: check every week that the code is being pushed to your repository.
• At delivery: collect the dependency list, documentation and walkthrough, and test every login.
• After launch: use the fix period, then remove access for anyone who no longer needs it.

Questions to ask before you hire anyone

Ask any studio or freelancer these questions during the sales call. The answers tell you a lot about how the handoff will go. For more on choosing who builds your app, read our guides on hiring an MVP agency.

• 1. Whose GitHub account will the code live in during the build?
• 2. Will the app be published from my Apple and Google accounts?
• 3. What documentation do I get at the end?
• 4. Do I get a list of dependencies?
• 5. What happens if I find a bug two weeks after launch?

How it works with BuildMVPFast

We build MVP apps for the web, iOS and Android. You can see how the build works on our MVP development page. Questions about your handoff? Book a call. It's a free 30 minute call. Here is what you get:

• Fixed at $3,460.
• Delivered in about 20 days, with progress shown every week.
• Design included.
• Code 100% yours, on your GitHub.
• 2 weeks of fixes after launch.

What should I receive when my app is delivered?

You should receive:

• A GitHub repository your company owns.
• App store and hosting accounts in your company's name.
• A list of third-party services and dependencies.
• Documentation for running and deploying the app.
• A clear post-launch fix period.

Should the app be published under my developer account or the agency's?

Yours. Create your own Apple Developer and Google Play Console accounts and add the developer as a team member. That way you control updates, store listings and revenue from the first release.

How can I check the code is really mine if I can't code?

Log in to GitHub with your own account. Open the repository, check that your role is Owner or Admin, and look at the commit history. You don't have to read the code for any of these checks.

When should the handoff happen?

It should start before the build. Set up the accounts in your name on day one and invite the developer, so there's very little left to transfer at the end. At final delivery, you collect the documentation and the dependency list and test every login.