What decides the cost of a mobile app

Two businesses ask for "a booking app". One pays a fraction of what the other pays, and both get exactly what they needed. The difference is never the word "app". It is a handful of decisions, most of which you can make before you speak to anyone. This guide lists them, in the order they usually matter.

Our own packages and starting prices are on the pricing page. Each one comes with a written list of what is included, because a number without the decisions behind it would mislead you. What follows is what moves the number, with us or with anyone else.

1. How many screens, and how many kinds of user

Count the screens a person would tap through, roughly. A list, a detail view, a form and a confirmation is four. Then count the kinds of people who log in: customers, staff, managers, admins. Each kind of user usually needs its own set of screens and its own rules about what they can see.

Screens and user types are the biggest driver because every screen is designed, built, tested on two platforms and maintained afterwards.

2. One platform or two, and how

An app for iPhone and Android can be built once with a cross-platform tool such as Flutter, or twice, natively, in Swift and Kotlin. Building once is less work to build and much less to maintain. Building natively is the right call when the app depends heavily on features specific to one platform. Most business apps are built once.

If you only need one platform for now, say so. It is a real saving.

3. Does it need a backend, and does one exist

Almost every useful app stores records somewhere other than the phone: bookings, orders, customers, jobs. That "somewhere" is a backend: a database and an API that the app talks to. If you already have a system with an API, the app connects to it. If not, the backend is built as part of the project, and it is often a third to a half of the work.

Describe what you already have: a website with a database, an accounting system, a spreadsheet, nothing.

4. What it connects to

Every outside service adds work: card payments, SMS, email, maps, calendar sync, accounting software, a card reader, a printer. Some are quick because the provider gives a well-made kit. Others are slow because the provider's documentation is poor or the service is unreliable and needs careful error handling.

List every connection you can think of. The list is more useful to a developer than any description of the app.

5. Offline, real time and notifications

Three features are easy to say and hard to build well:

• Offline use. The app must work with no signal and sync later without losing or duplicating anything.
• Real time. Several people see the same thing change at the same moment: a dispatcher watching drivers, a kitchen screen watching orders.
• Notifications. Reliable push messages on both platforms, with rules for who gets what and when.

Each is worth having when the job needs it. Each should be a conscious decision, not an assumption.

6. Design depth

A clean, standard look using each platform's conventions is quick, and it is what most business apps should use. Custom illustration, animation and branded components are a separate line of work, before and during the build. Decide which you need. Staff apps rarely need custom design. Consumer products often do.

7. Testing, security and the stores

An app that handles payments, personal data or health information needs more careful testing and security review than an internal checklist tool. Both stores also review each app before it is listed, and each has a developer account fee: Apple's is annual, Google's is a one-off registration fee. The current amounts are on their pages, linked at the end.

Store review adds days to every release and sometimes a rejection to fix. Good developers plan for that; it should not be a surprise line on an invoice.

8. What happens after launch

The price of building is not the price of owning. Phones and store rules change every year. Services the app depends on change their terms. Something breaks on a Friday. A maintenance agreement covers this, with a promised response time. Ask for it as a separate item so you can compare it honestly.

How to describe your own project

Write one page, in your own words, with these headings:

1. Who uses it, and how often. The three main kinds of user.
2. The main job. What a user does in a normal session, step by step.
3. Screens. Your rough count, or a list.
4. Platforms. iPhone, Android, both; and whether you need a web version.
5. What exists already. Website, database, accounting system, spreadsheets.
6. Connections. Payments, messaging, maps, hardware, other software.
7. Must-haves from section 5. Offline, real time, notifications: which, and why.
8. What can wait. Everything that would be nice in a second version.

Send that page to any developer, including us, and you will get a more useful answer than from a week of emails. If a developer gives you a firm price without asking any of these questions, be careful: either the price will change later, or the scope has been guessed.