A question list for founders and tech leads before the contract is signed.
The proposal lists features, design, and a twelve-week timeline. It says "App Store submission included" in one bullet. It does not say who owns the Apple Developer account, how release builds get produced, or what happens to signing keys when the engagement ends.
Those gaps are how teams end up with a finished app and no path to production. Store launch is not a footnote; it is a workstream with owners, tools, and credentials.
Use this question list when you compare mobile app development services vendors. It pairs with technical due diligence on staging demos and API contracts in our Hashnode post on proposal signals.
Plain terms (quick reference)
App Store Connect: Apple's portal for uploading iOS apps and managing listings.
Play Console: Google's portal for Android app releases.
Release CI: Automated pipeline that builds installable app packages for stores.
TestFlight: Apple's channel for beta installs before public App Store release.
Signing keys: Cryptographic credentials that prove your app is authentic.
Store account ownership
- Whose Apple Developer Program account will the app live under? (Yours vs vendor's)
- Whose Google Play developer account will publish the Android app?
- If the vendor holds accounts temporarily, what is the migration plan to your org?
- Who pays annual store fees after launch?
- Who has admin access to both consoles on day one after handover?
Rule of thumb: Your company should own production store accounts for anything customer-facing long term.
Submission scope and responsibilities
- Who fills App Store and Play listing forms (screenshots, descriptions, categories)?
- Who writes or hosts the privacy policy URL required by both stores?
- Who provides test credentials for Apple and Google reviewers?
- How many review rejection cycles are included in the quote?
- Is push notification setup, in-app purchases, or other entitlements in scope?
"Submission included" without naming forms and rejections often means one upload attempt only.
Release CI and build pipeline
- Is there an automated pipeline (GitHub Actions, Codemagic, Bitrise, etc.) for release builds?
- Who maintains signing certificates and provisioning profiles (iOS)?
- Who holds the Android keystore, and is it backed up securely?
- Can you trigger a release build without the vendor's laptop?
- Are environment settings (API base URLs) injected per build flavor?
If releases depend on one developer's machine, bus factor and launch risk are both high.
Test and beta channels
- Will you get TestFlight or Play internal testing access before public launch?
- Who invites stakeholders to beta builds?
- How are crash reports shared during beta (Firebase, Sentry, etc.)?
- What is the exit criteria from beta to production submission?
Beta access is your best preview of launch-week behavior.
Handover deliverables
Ask for this list in the statement of work:
- Source code repository with documented setup steps
- CI configuration and secrets inventory (not the secrets themselves in email)
- Store console admin for your team or documented transfer steps
- Backend credentials and hosting ownership if the vendor ran servers
- Architecture overview (one diagram is enough for v1)
- Post-launch support window and hourly rate after it ends
A zip file without CI and store access is not a complete handover.
Questions for the discovery call
If you are still in early conversations, prioritize:
- "Walk me through who clicks upload on launch day."
- "Show me the last project where the client owned the store accounts from day one."
- "What happens if we part ways after MVP but before v2?"
For the non-technical side of first calls (users, v1 scope, launch owner), see (pending: what a good mobile app discovery call should clarify).
For a full shortlist guide with red flags and FAQ blocks, see how to choose a mobile app developer.
What blocked your last vendor comparison: store ownership, CI, or handover scope?
Top comments (0)