Nobody will give you a price over the phone, and it is not evasion: "an app" can be two weeks or two years.
What can be explained is what moves the number. With that you can estimate for yourself whether what you have in mind is a small project or a big one, before asking for the first quote.
The five things that move the price
1. Whether there are users and accounts
An app that only displays information is far simpler than one where someone signs up. Accounts mean registration, password recovery, permissions, sessions, account deletion — Apple requires it — and a server behind. It is the biggest jump between two apps that "look similar".
2. Whether it works offline
That is the difference between showing data and syncing it. Storing locally is easy; resolving what happens when two people changed the same thing at different times is not. If your people work with poor signal — couriers, field technicians, market stalls — it is worth it, but it has to be budgeted.
3. What it has to connect to
A standalone app is one project. One that queries the ERP, charges through a gateway and issues electronic invoices is four projects, three of which depend on systems you do not control.
Here the timeline stretches for non-technical reasons: waiting on credentials, waiting on sandbox access, waiting for the other vendor to reply.
4. How custom it has to look
An app built from standard components goes fast. One with bespoke design on every screen, animations and a strong identity takes considerably longer, and sometimes that is worth it and sometimes it is not. It depends on whether your app is the face of the brand or an internal tool.
5. Android, iOS or both
This is the decision that moves the most money.
Building two native apps means writing everything twice: two codebases, two teams, every fix done twice. With Flutter you write once and ship to both stores, looking the same on both.
It is not magic and it does not fit everything — if the app depends on something very platform-specific you still drop to native code — but for the vast majority of business apps the math changes completely. It is what we use for our mobile apps.
What almost nobody budgets
And it is what stings later:
- Developer accounts. Apple charges yearly and Google once. They belong to your company, not the vendor, and that matters the day you change vendors.
- Store review. Apple reviews by hand and can reject. Plan for an extra round, because there almost always is one.
- The server. If there are accounts or data, something is running every month.
- Maintenance. Android and iOS ship a new version every year. An app without maintenance does not break all at once: it drifts out until one day it will not open.
That last one is the most often ignored. An app is an annual commitment, not a one-time purchase.
How to ask for a quote that helps
Instead of "how much does an app cost?", this brings useful answers:
- Who will use it and what for. One sentence is enough: "couriers register the delivery and the customer signs on the phone".
- Whether it has to work without signal. Yes or no.
- What it connects to, and whether you already have those credentials.
- When you need it, and what happens if it is late.
- What you had in mind investing, even as a range. Not so we charge you that: so we can tell you whether it is enough, and if not, what can be done with what there is.
That last point saves weeks on both sides.
A middle path
If the budget does not cover everything, it can almost always be split: a first version solving the most painful step of the process, in production, with real people using it. You learn more from three weeks of real use than from three months of meetings.
Tell us what process you want to solve and we will tell you what it takes. Let's talk.