How to Choose a Mobile App Development Company: 12 Questions to Ask Before You Sign

Most mistakes in hiring an app developer are made before the contract, and most of them come down to who controls the accounts, the code and the store listing. The twelve questions below are grouped by theme. Each has the answer you want, the answer that should worry you, and the reason. They apply to any studio, including ours: we are a Shopify Select Partner that also builds apps, and our mobile app development work is quoted in writing like every other project. Use these on us as well.

How to use the list

Ask the questions in writing and keep the replies. A good partner answers specifically and does not mind being asked twice. Treat the red-flag answers as information about how the project will feel in month four, not as proof of bad faith. Store rules change, so the platform facts below were checked on 9 November 2026 against Apple's and Google's own pages (listed in this article's sources); check them again before you sign.

Two or more red flags in the first group, ownership, are enough to walk away. The later groups can sometimes be fixed by negotiation.

Group one: who owns what

1. Which developer accounts will the app be published under?

Good answer: your own Apple Developer and Google Play accounts, registered to your business, with the studio added as a team member.

Red flag: "We will publish under our account and transfer it later."

Why: Transfers are possible but they are a process with conditions. Apple documents that an app can be transferred while staying on the App Store, keeping its reviews and ratings and its Bundle ID, but only if it meets transfer criteria, and some features such as TestFlight beta testing and auto-renewable subscriptions need preparation first. Google Play documents transfers too, and notes that test groups do not transfer and that integrated services such as analytics and Firebase need manual updates afterwards. Starting in your own accounts avoids all of it. Note that enrolling a company with Apple requires a D-U-N-S Number registered to a legal entity, and Google Play asks for one for organisation accounts, so start that paperwork early; it is not instant.

2. Where does the source code live, and who is the owner on day one?

Good answer: a repository in an organisation you own, with the studio invited in, and the licence and ownership terms written into the agreement.

Red flag: "You will get the code at the end", or code delivered only as a compiled build.

Why: Without the code you cannot change studios. This is a contract and access question, not a technical one, and no store rule will rescue you from a missing repository.

3. Which outside services does the app depend on, and whose account pays for them?

Good answer: a written list of every service (push notifications, analytics, crash reporting, backend, maps, email), each registered to you.

Red flag: shared logins, or services created under the developer's personal email.

Why: Those dependencies are what quietly break an app when the studio relationship ends. Google's own transfer guidance lists analytics, Firebase, cloud projects and ad integrations among the things that need manual attention after a move.

Group two: choices and proof

4. Native, cross-platform or something else, and who maintains that choice?

Good answer: a reason tied to your app, not the studio's preference, plus a view on who can maintain the chosen stack in three years. See our comparison of native and cross-platform apps for the trade-offs; Flutter and FlutterFlow are one option we build with, not the only answer.

Red flag: the same recommendation for every client.

Why: Technology choice should follow what the app must do and who will own it afterwards.

5. Which apps have you shipped that I can install today, and what exactly did you do on each?

Good answer: store links you can open, with a clear split between what they built and what the client or another vendor built.

Red flag: screenshots, design files or "under NDA" for everything.

Why: A live listing is the only proof that the team has been through store review. Confidentiality is real, but a studio with no references of any kind has not earned your trust yet.

6. Who will write the code, where are they, and what happens if they leave?

Good answer: named roles, working hours and overlap with yours, and a documented handover routine.

Red flag: a senior person sells it and an unnamed subcontractor builds it.

Why: Location is not the issue; clarity is. Our own team is in Pakistan and we say so plainly. Ask any studio the same, then check whether the answer matches the contract.

Group three: testing and the store rules

7. How is the app tested, on which real devices, and when do I see a working build?

Good answer: test builds on real phones in regular intervals, a named person responsible for testing, and a plan for beta distribution.

Red flag: "We test on emulators and show you at the end."

Why: Google also requires newer personal developer accounts to run a closed test, with a stated minimum of twelve testers opted in for at least fourteen days, before applying for production access. Ask who recruits those testers and whether the schedule allows for the wait. This applies to personal accounts the page describes; it does not say what applies to organisation accounts, so confirm which account type you are using.

8. How do you plan for store review and rejections?

Good answer: review and resubmission time built into the plan, no promised approval date, and familiarity with the specific rules that catch apps out. Apple's guidelines ask that submissions be complete, with demo account details and the back end switched on during review. They also say apps should be more than a repackaged website and reject apps built from a commercialised template or app generation service unless the content provider submits them directly. Google requires new apps and updates to target a recent Android version, and that bar moves forward over time.

Red flag: any promise of approval or of a launch date.

Why: Review is outside the studio's control. A confident date is a guess, and a promise is a sign of inexperience.

9. What user data will the app collect, and who completes the privacy declarations?

Good answer: the studio asks what data you need before design starts, drafts a privacy policy for your review, and builds account deletion if people can create accounts.

Red flag: "We will fill in the forms at the end", or copying another app's declarations.

Why: Apple requires a privacy policy link in the store metadata and inside the app, and requires in-app account deletion when the app supports account creation. Google Play requires every app to complete its Data safety form, even if it collects nothing, and says the developer alone is responsible for the accuracy of the declarations. Mistakes here are yours, not the studio's.

Group four: money, support and exit

10. Will the app sell anything, and how will payment work on each store?

Good answer: the studio raises it during scoping and explains which purchases must use each store's in-app purchase system.

Red flag: planning to take card payments for digital content without mentioning store rules.

Why: Apple's guidelines say digital content and feature unlocks must use in-app purchase, with exceptions for physical goods and services consumed outside the app, and with regional rules on external purchase links. Ask the studio to cite the current guideline for your case rather than recalling it.

11. What does support after launch cover, in writing?

Good answer: a written scope: crash fixes, operating system updates, store policy changes, who responds, and what counts as new work.

Red flag: "It will just work" or open-ended promises with no scope.

Why: Apps need maintenance because the platforms keep moving. Google's target-level requirement is one example, and an app that falls behind is limited in which devices and users it can reach.

12. How is the work quoted, changed and ended?

Good answer: an itemised written quote with assumptions, a process for changes, milestone-based review and a handover list if you part ways: repository, accounts, keys, documentation.

Red flag: one lump number, no assumptions, no exit terms.

Why: Most disputes arise from unwritten assumptions. We do not publish prices because a number without your scope is not meaningful, and we put scope and assumptions in the written quote for the same reason.

When this advice is wrong

You may not need a studio. If your app is mostly a website in a wrapper, Apple's guideline against repackaged websites is a risk worth understanding first, and a good website may serve you better. If you need a quick internal test, a no-code tool can be enough. And a very small project does not need all twelve questions answered in a long document; two or three of them, asked in an email, will do. The ownership group is the exception: never skip it.

Website Prism Ltd (England and Wales no. 17462217) delivers remotely from Pakistan. Usama Afzal has delivered 800+ projects over 8+ years, mostly via Fiverr. If you would like these questions answered about our own process in writing, send us a short brief and ask for a written quote. We make no promises about store approval or launch dates.