Know what kind of app you are buying
Mobile app covers products with very different demands. A company that is excellent at one kind can be a poor fit for another, so place your project first.
| Kind of app | Typical example | What it demands from the company |
|---|---|---|
| Customer account app | Bookings, orders or statements for an existing service | Integration with your systems, sign-in and dependable releases |
| Consumer product | A habit, content or social app the business is built on | Product design, onboarding, analytics and fast iteration |
| Field or staff app | Inspections, deliveries, sales visits | Offline work, device management and data that syncs correctly |
| Two-sided marketplace | Customers on one side, providers on the other | Two apps, payments, matching and an admin system |
| Device-connected app | An app that controls or reads hardware | Bluetooth or network protocols and testing with the real device |
See how they decide between native and cross-platform
You do not need to make this choice yourself. You need a company that makes it for reasons that come from your app. Ask them to explain the recommendation, then check it against the table.
| Approach | Usually fits when | What it costs you |
|---|---|---|
| Native, with Swift for iOS and Kotlin for Android | The app depends on device features, heavy graphics or the best possible feel on each platform | Two codebases to build and maintain |
| Cross-platform, with React Native or Flutter | The app is mostly screens, forms and data, and both platforms must launch together | Some platform features need extra native work |
| Web app that installs from the browser | Reach matters more than device features, and store presence is not required | Limited access to device features, and no store listing |
Be careful with a company that recommends the same approach to every client. Our comparison of native and cross-platform development goes through the trade-offs in more detail.
Ask for evidence you can check yourself
- 01
Apps you can install today
What to look forDownload two or three. Check how recently each was updated, read the store reviews and use the app for ten minutes on your own phone
- 02
A walk through one project
What to look forWhat the client asked for, what changed along the way, what went wrong and how it was handled
- 03
The people who would build yours
What to look forA conversation with the engineer and the designer, not only an account manager
- 04
A sample of their working documents
What to look forA release checklist, a test plan or a handover document with private details removed
- 05
A reference you can call
What to look forSomeone whose app has been live long enough to have needed updates
Ask about the part most buyers forget, which is after launch
A website can sit untouched for a long time. An app cannot. Apple and Google usually release a major new system version each year, store rules change, and devices with new screen sizes appear. An app that is not maintained gradually stops working well, and the stores can remove apps that have gone a long time without an update.
- 01
Whose name are the App Store and Google Play accounts in?
A strong answer coversYours. The company is added as a member of your accounts, so the app and its users stay with you
- 02
Who handles store review and rejections?
A strong answer coversThey prepare the listing, the privacy details and the review notes, and they deal with a rejection as part of the project
- 03
How are new iOS and Android versions handled each year?
A strong answer coversTesting against the beta versions before public release, under a maintenance agreement with a stated scope
- 04
How will we know when the app crashes?
A strong answer coversCrash and performance monitoring from the first release, with someone who reads the reports
- 05
Who owns and runs the backend?
A strong answer coversAn agreed owner for the hosting accounts, with documentation of the API and the data model
- 06
How do releases work after the first one?
A strong answer coversA repeatable release process with testing, staged rollout and a way to fix a bad release quickly
Compare proposals on what they include
App proposals differ most in what they leave out. Before you compare prices, lay the proposals side by side and fill in the same rows for each.
Three proposals for a clinic booking app
A clinic group asks three companies for an app where patients book and manage visits. The companies and details are invented to show how to read proposals side by side.
| Proposal A | Proposal B | Proposal C | |
|---|---|---|---|
| Approach | Cross-platform | Native, two apps | Cross-platform |
| Backend and admin | Not mentioned | Included | Included, in the clinic's cloud account |
| Connection to the practice system | An assumption in a footnote | Included | Included, with a test plan |
| Store submission | Extra | Included | Included |
| After launch | Not mentioned | A monthly retainer | A support period, then an optional plan |
| Ownership | Not stated | Code on delivery | Code and accounts from the first day |
Proposal A has the lowest price and is the least complete. Once the backend, the integration and the store submission are added, it may no longer be the cheapest. B and C can be compared fairly, and the difference between them is the platform choice and when ownership starts.
Good signs and warning signs
Good signs
- They ask who the users are and what they do today without the app
- They suggest a smaller first release than you asked for
- They raise store rules, privacy labels and account deletion before you do
- They test on real devices, including older and cheaper ones
- They talk about the backend as much as the screens
Warning signs
- A fixed price after one short call
- Screens designed before anyone has discussed the flows
- The app would be published under their developer account
- No plan for yearly system updates
- A portfolio of apps that are no longer in the stores
A checklist to run before you sign
Mobile app contract checklist
0 of 10 checkedWhat to do next
Write down what the app must let a user do, in a page. Our guide to writing a mobile app requirements document has a template, and if this is a first version, planning a mobile app MVP will help you cut it to size.
If Alpha Expansion is on your list, our mobile app development page sets out how we work and what you receive. You can also send us your notes and we will tell you which approach we would recommend and why.
Common questions
How much does it cost to build a mobile app?
It depends on the number of user roles, the screens and flows, the systems the app connects to and whether a backend exists. A serious company will not give a figure before understanding these. Ask for a proposal that separates design, the apps, the backend and maintenance, so you can see where the cost sits and what could be reduced.
Should I build for iPhone or Android first?
Build first for the platform most of your users have, which you can often learn from your website analytics. With cross-platform development, both can usually launch together. Launching on one platform first makes sense when you are still testing the idea and want to learn before paying for two.
Do I need a backend for my app?
Almost always. If users sign in, see their own data, receive notifications or share anything with other users or with your staff, something on a server has to store and deliver it. Ask each company whether the backend is in their price, because it can be as much work as the app itself.
Who should own the App Store and Google Play accounts?
Your organization. The accounts hold the app, its reviews, its users and its revenue. If a development company publishes the app under its own account, moving it later takes their cooperation. Open the accounts yourself and add the company as a member.
Can I change development company after launch?
Yes, if you own the source code, the store accounts and the hosting, and the documentation is reasonable. The new team will need time to learn the code. A short audit of the existing app is a sensible first step before they commit to estimates.