Short answer: choose the company that has shipped and maintained apps similar in shape to yours, puts the store accounts and code in your name, gives you a line-item scope with exclusions, shows you installable builds every week or two, and is willing to tell you what it is not good at. Price matters, but only between proposals that cover the same scope.
A note on who is writing. BBR Studio Labs is an app development studio, so we are one of the companies this checklist applies to. We have written it so that it can be used against us as readily as anyone else.
What to evaluate, in order of importance
1. Evidence of shipped apps
An app that is live in the stores, under a name you can verify, is worth more than any number of case-study pages. Install it. Use it on a poor connection. Look at when it was last updated, because an app untouched for two years tells you about the maintenance habits of whoever owns it. Apps similar in shape to yours count more than apps in your industry: a team that has built subscriptions, maps and chat can build them in any sector.
2. Honesty about technical approach
Ask how they would build your app and why. A good answer names an approach, native, cross-platform or hybrid, explains the trade-off for your particular product, and mentions what the approach is bad at. Be cautious of a vendor who claims to be equally expert in every framework. Small teams specialise. The background you need for this conversation is in native vs cross-platform development.
3. Ownership terms
The store developer accounts, source code repository, signing keys, hosting and third-party service accounts should all belong to your company. This is the difference between hiring a supplier and acquiring a dependency. More on this below.
4. The quality of the proposal
A proposal is the first deliverable you see. If it is vague, the project will be vague.
5. Communication
Notice how the vendor behaves before you pay them: response times, clarity of writing, whether they ask questions that show they have read your brief. It will not improve after signing.
6. Price
Last, deliberately. A price means something only when attached to a scope. Once two proposals cover the same work, compare the totals. Our app cost guide shows how to check whether a number is plausible.
Questions that are specific to apps
General due-diligence questions about process, contracts and team are collected in questions to ask a software development agency. The ones below apply to mobile work in particular, and they are where inexperienced vendors are exposed.
| Question | What a good answer sounds like |
|---|---|
| Whose Apple and Google developer accounts will the app be published under? | Yours. You register the accounts in your company’s name and invite the vendor as a team member. They explain the enrolment steps and warn you it can take time |
| Who holds the signing keys and certificates? | You do, or the store manages them under your account. They are documented at handover |
| How will I see progress? | Installable builds through TestFlight and Google Play internal testing every week or two, from early in the build, not screenshots |
| Which devices and OS versions will you test on? | A specific list, including at least one older and one small-screen device for each platform, written into the scope |
| What is your release process? | Separate development, staging and production environments; version numbering; staged rollout; a way to get an urgent fix out |
| Who handles store submission and rejections? | They do, as part of the scope. They can describe common rejection reasons and do not promise approval, since that is Apple’s and Google’s decision |
| How will payments work in the app? | They know that digital goods and subscriptions generally have to use store billing while physical goods and services use a payment provider, and they raise the commission without being asked |
| What analytics and crash reporting will be in place at launch? | Named tools, a list of the events to be tracked, and access for you to the dashboards |
| How are push notifications set up, and who owns those accounts? | Under your accounts, with keys documented |
| What are the privacy requirements for my app? | They mention store privacy declarations, permission explanations, account deletion inside the app, and a privacy policy, and they note that legal review is your responsibility |
| What happens after launch? | A defined warranty period for defects, then an optional maintenance plan with a stated scope. They explain why apps need yearly updates |
| If we part ways, what do I receive? | The repository with full history, build and release documentation, credentials and accounts, all of which were yours from the start |
What a good proposal contains
- A restatement of your product in their words, showing they understood it
- A feature list split into first release and later, with acceptance criteria for the first release
- The technical approach and the reason for it
- Line items for design, app, backend, admin panel, testing, store submission and project management
- Explicit exclusions and assumptions
- Supported platforms, OS versions and test devices
- A timeline with milestones defined as working software, not dates alone
- Payment schedule tied to those milestones
- Who will work on the project and who your point of contact is
- Ownership of code, accounts and IP, and when it transfers
- How change requests are priced and approved
- Post-launch warranty and maintenance options
If a proposal is a single page with a total at the bottom, ask for the breakdown. A vendor who cannot or will not provide it has not estimated your project; they have guessed.
Red flags
- “We will publish it under our account to make it easier.” Easier for them. Moving an app between accounts later requires the cooperation of the very people you may be trying to leave.
- A quote within an hour, with no questions. Nobody can price an app from two paragraphs.
- A price far below the others. Something is missing. Usually the backend, the admin panel, testing or the second half of the features.
- Guaranteed store approval, guaranteed downloads or guaranteed rankings. None of these is theirs to guarantee.
- No live apps you can install, or apps whose publisher cannot be connected to the vendor and no explanation of why.
- Yes to everything. A competent team pushes back on scope, questions a feature, or tells you that a requirement is expensive.
- No builds until the end. If you cannot install the app until month three, you cannot correct anything until month three.
- Large upfront payment with no milestones. A deposit is normal. Most of the fee before any working software is not.
- The people on the sales call will not be involved in the work, and nobody can tell you who will be.
- Code in their repository “until final payment”, with no access for you. Read access from day one costs them nothing and protects you.
A comparison scorecard
Score each vendor from 0 to 3 on every row after the proposals are in. The weights are a suggestion; adjust them for your situation, but decide them before you read the prices.
| Criterion | Weight | Vendor A | Vendor B | Vendor C |
|---|---|---|---|---|
| Live, verifiable apps of similar shape | ×3 | |||
| Store accounts, code and keys in your name | ×3 | |||
| Proposal detail: line items, exclusions, acceptance criteria | ×3 | |||
| Clear reasoning for the technical approach | ×2 | |||
| Testing plan with named devices and OS versions | ×2 | |||
| Frequent installable builds | ×2 | |||
| Communication quality during the sales process | ×2 | |||
| Release, analytics and crash-reporting process | ×1 | |||
| Post-launch warranty and maintenance terms | ×1 | |||
| Working-hours overlap and language | ×1 | |||
| Price for an equivalent scope | ×2 |
Any vendor scoring zero on account and code ownership should be removed regardless of the total.
A selection process that works
- Write the brief and send the same document to three to five companies.
- Hold one call with each. Pay attention to the questions they ask you.
- Request written proposals against the checklist above.
- Install their apps and, where offered, speak to a past client.
- Score them before looking again at the prices.
- Start small. A paid discovery or design phase of one to three weeks is a low-risk way to find out what working together is like before committing the full budget.
If the app is a first version of a new product, the MVP-specific considerations in choosing an MVP development company also apply. To see how BBR answers these questions, read our mobile app development page and how we work, or look at the apps we have published ourselves in the case studies.