Mobile App Project Intake Checklist: What to Collect First
Everything a client needs to hand over before an app gets built — store accounts, branding, API keys, legal pages — grouped with a reason and timing.
Why app intake is its own list
A website project stalls on a missing logo or a login nobody can find. An app project stalls on those too, plus a category a website never has: accounts only the client can create, submissions only the account owner can approve, and a store review process that happens once, late, and rejects the whole build over one missing piece. A privacy policy URL that's a nice-to-have on a website is a hard submission requirement here. A payment integration that could ship in week three of a website blocks the first TestFlight build if it's core to the app.
This list is organized the same way as our general website project intake checklist, but the categories and the timing calls are different enough that treating an app like "a website with an icon" produces avoidable delays. If the project also needs a new brand identity, pair this with the logo and brand design brief checklist — that one covers the mark itself; this one covers everything around it.
The checklist, group by group
Before kickoff means the project can't meaningfully start, or starting without it means redoing work later. Can come later means development can proceed with a placeholder or a sensible default until the real thing arrives.
Accounts and access
| Item | Why you need it | Timing |
|---|---|---|
| Apple Developer Program enrollment, under the client's own identity | Only the client can start this, and it's outside your control once requested — hand it off on day one rather than waiting to need it. | Before kickoff |
| Google Play Console developer account, under the client's own identity | Same reasoning as Apple: it has to be the client's account, requested before you're blocked on it. | Before kickoff |
| You added as a collaborator with a development role, not full account ownership | Lets you build, test, and submit without holding the keys to an account you don't own — more below. | Before kickoff |
| Access to an existing app listing, if you're taking over a live app | A transfer or collaborator request from the previous developer's account, arranged before you need to ship an update. | Before kickoff if replacing an existing app |
| App Store Connect / Play Console API credentials, if you're automating builds or releases | Only needed once a CI/CD pipeline exists to consume them. | Can come later |
Identity and store listing assets
| Item | Why you need it | Timing |
|---|---|---|
| App name and app icon source file | The name may need reserving on both stores before someone else takes it, and the icon shapes a chunk of the design work. | Before kickoff |
| Store description (short and long, per store's format) | Needed for submission, not for building — placeholder copy is fine until then. | Can come later |
| Screenshots or the raw material to produce them (mockups can be generated once the UI exists) | Can't really be finished before there's a UI to screenshot, though brand direction for them should be settled early. | Can come later |
| Category and search keywords | Affects discoverability, not functionality — a submission-time decision. | Can come later |
| Support URL and privacy policy URL | Both stores require live URLs at submission; the privacy policy needs real content, not a placeholder, if the app collects any user data. | Can come later, but before submission |
Content
| Item | Why you need it | Timing |
|---|---|---|
| Which languages the app needs to support | Changes the technical setup for text, layout, and date/number formatting — expensive to retrofit once the app is built around a single language. | Before kickoff |
| In-app copy — onboarding text, screen labels, empty states, error messages | Structure and layout can proceed with placeholder text; final copy is a content pass, not a redesign, once it exists. | Can come later |
| Licensed media (stock photos, icon sets, fonts) the client has rights to | Confirms what's usable without a separate licensing conversation mid-build. | Can come later |
| Legal text that has to live inside the app itself (a terms acceptance screen, disclaimers) | Distinct from content that only needs to exist online — some of it has to be a screen the user sees and accepts. | Can come later, but before submission |
Integrations and credentials
| Item | Why you need it | Timing |
|---|---|---|
| API keys for any service the app's core function depends on (maps, payments, a booking system) | If the app doesn't work without it, it's part of the build from day one, not an integration to add later. | Before kickoff if core to the app |
| Backend or CMS credentials, if the app talks to an existing system | Same reasoning as a website keeping its existing hosting: confirm access exists before integration work starts. | Before kickoff |
| Push notification credentials (an APNs key for iOS, a server key for Android) | Only needed once push is actually being wired up and tested. | Can come later |
| Payment processor account, under the client's own name, if the app takes payments | Ownership matters even more here than for a website — see the note below. | Before kickoff if payments are core |
| Social login app credentials (a Facebook or Google OAuth app, if "sign in with…" is planned) | A configuration step that runs in parallel with the rest of the build, not a blocker for starting it. | Can come later |
Legal and compliance
| Item | Why you need it | Timing |
|---|---|---|
| Privacy policy | Required for store submission the moment the app collects any user data; it should come from the client or their lawyer, not be invented for them. | Before kickoff |
| What user data the app actually collects and why | Both stores ask for this explicitly at submission, and the answer shapes whether a consent screen is needed at all — better known before the data model is built. | Before kickoff |
| Terms of service | Carries legal weight the same way a privacy policy does. | Can come later, but before launch |
| Age rating questionnaire answers (violence, user-generated content, gambling elements, etc.) | A submission requirement, not a build requirement — answered once the app's content is settled. | Can come later |
| Industry-specific disclosures (health data, financial services, children's apps) | Requirements vary by sector and store policy; confirming this is the client's responsibility, not something a default template covers. | Before kickoff for regulated industries |
Testing and release
| Item | Why you need it | Timing |
|---|---|---|
| Minimum OS version and device range to support | Affects which features are safe to use — settle it before writing code that assumes a newer OS than the client's users actually have. | Before kickoff |
| Email addresses for internal testers (TestFlight, Play internal testing track) | Needed once there's a build worth testing. | Can come later |
| Expectations for analytics or crash reporting | Cheap to wire in during the build, awkward to bolt on once the app has real users and a data gap. | Can come later |
| A hard release date, and what's driving it | An event-driven launch has a real deadline shaping how much testing time is realistic; one without has more room. | Before kickoff |
| Who has final sign-off to submit to the stores | Submission is often the one step that can't be undone quietly — confirm who approves it once, at the start. | Before kickoff |
Why store accounts should belong to the client, not you
It's tempting to enroll the client's app under your own developer account — it's faster, you already have one, and the client doesn't need to fill in a form. It's also the single most common source of a painful conversation later.
A developer account is the app's home. Its identity, review history, existing users' ability to receive updates, and any active subscriptions all live under that account, not under the app itself. If the account belongs to you and the working relationship ends, moving the app to the client's own account is a formal transfer process between two developer accounts, not a quick setting change, and it can interrupt the app's ability to ship updates while underway. If the account belongs to the client from the start, ending the relationship just means removing your collaborator access — the app never has to move at all.
The same logic that applies to a hosting login applies here, at higher stakes: the account that can delete the app or hand it to someone else should be the one the client controls. Add yourself as a team member with a role scoped to what the work needs — both Apple and Google support this — rather than building under an account the client needs your cooperation to ever leave.
Handing over credentials and API keys safely
Everything in the integrations and credentials group above is either an invite (add me as a collaborator with a specific role) or a secret (a single API key, a payment processor's secret key, a backend password with no scoped-access option). Treat them differently: an invite should always be scoped to what the task needs, the same principle covered in more depth in how to ask clients for logins and passwords securely. A secret that can't be scoped — a raw API key, a webhook signing secret — shouldn't travel by email or chat at all, since it sits there indefinitely once sent. BriefGate's secret item type exists for exactly that case: the value is encrypted the moment the client enters it and released once to whoever asked, rather than living on in an inbox.
Where BriefGate fits
Requesting the accounts and can-wait items on this list separately — a form for one, an email for another, a follow-up call for a third — is how a client ends up needing four reminders about four different things. BriefGate lets an agent, or you from the dashboard, declare this whole checklist as one set of typed items: secret for the payment processor key, image for the app icon, structured for the data-collection answers, all covered in item types. The client gets one branded portal and one progress bar instead of a scattered thread, BriefGate chases the outstanding items on a schedule you set, and the accounts-and-access group can even be marked as your own to-dos rather than the client's, using an owner-assigned item, if it's you who needs to remember to request the transfer.