What It Takes to Build a Mobile App
Last updated:
The app is half the project
Clients budget for “an app” and receive a quote covering considerably more, which feels like padding until it is itemised. It is not padding. A mobile app is a client for a system, and the system has to exist.
- A backend with an API, a database and authentication
- An admin interface, because someone will need to manage content or users
- Developer accounts with Apple and Google, and the identity checks that come with them
- Store listings: screenshots for several device sizes, descriptions, a privacy policy
- Crash reporting and analytics, without which you are blind after release
- A release process that can ship a fix in days rather than weeks
The two obligations nobody expects
First, app review. Both stores review submissions and both reject for reasons that are not always predictable. Budget one to two weeks for the first submission and expect at least one rejection; it is normal rather than a sign of a problem.
Second, forced maintenance. Apple and Google update their operating systems annually and periodically raise the minimum SDK an app must target to stay in the store. An app nobody touches for two years is eventually removed — not because it broke, but because it stopped complying.
A website you ignore keeps working. An app you ignore is delisted. That difference is the single most important thing to understand before commissioning one.
What the build actually contains
| Component | Share of effort |
|---|---|
| Backend and API | 25–35% |
| App: screens and logic | 30–40% |
| Authentication and accounts | 8–12% |
| Offline handling and sync | 0–15%, depending |
| Push notifications | 3–6% |
| Store submission and assets | 3–5% |
| Testing across devices | 10–15% |
Offline handling is the swing factor. An app that assumes connectivity is much simpler than one that must work in a basement, and field-service apps almost always need the latter.
Testing on real devices
Simulators lie. They do not reproduce a two-year-old mid-range Android phone on a poor connection with 8% battery, which is the device a good proportion of your users are holding.
- A current and an older iPhone
- Two or three Android phones across price brackets
- A tablet, if you claim to support one
- Throttled network testing, deliberately
- Low-battery behaviour, where background work gets restricted
What we need from you
- Apple and Google developer accounts in your company's name — start early, identity verification takes time
- Brand assets: icon, colours, and a name that is not already taken in the stores
- A privacy policy that accurately describes what the app collects
- Decisions on what version one does not do
- Someone to test the builds we send, weekly
The developer accounts are the item that most often delays a launch. Apple's business verification in particular can take a fortnight on its own, and it cannot be hurried.
The honest question before starting
Will people install this and open it again? An app that gets installed once and forgotten has cost you the same as one that is used daily.
The apps that succeed give someone a reason to open them weekly: a job list, an order status, a loyalty balance, a booking. If nobody has a weekly reason, a good mobile website usually serves the business better and costs a fraction.
Frequently asked questions
Do we need both iOS and Android?
Can you publish under our accounts?
What if Apple rejects our app?
How soon can we launch?
Considering an app for your business?
Tell us how often a customer would open it. That one answer usually settles whether you need an app or a much cheaper mobile site.
Related services
What we build for problems like this one