What it costs

What a mobile app costs

An app costs more than a website, and it is not a matter of complexity: it is that you pay for it twice, then every year. Twice, because iPhone and Android are two distinct systems. Every year, because both stores impose updates to stay publishable — an app nobody touches ends up withdrawn. The build quote says nothing about that part, and it is the part that decides whether the project survives. This page sets out the costing method, the items that recur, and what changes with a subscription where a team stays after publication.

1. Why you pay twice

That is the fact governing the whole budget, and the one most often discovered after asking for a first quote.

Two systems, two worlds. iOS and Android share neither the same language, nor the same display conventions, nor the same permission rules. Historically that meant two complete builds, so roughly twice the workload.
Shared technologies narrow the gap without erasing it. Writing a shared base is the norm today, but fine-tuning, testing and each platform's peculiarities still have to be done twice. Count a real supplement, not a doubling.
Two stores to satisfy. Each has its publication rules, its visuals to produce at the right dimensions, its texts to translate and its review to pass. It is administrative work in its own right, distinct from development.
A fleet of devices, not one device. Very different screen sizes, older system versions still in service. What the web settles with a style sheet here demands testing across several configurations.

For equal scope, an app therefore costs structurally more than a website. The real question is not how to pay less, but whether the app is necessary — that is section 5, and it deserves reading before you ask for a quote.

2. Costing a build, item by item

As with a website, no reference price exists. Here are the items to have costed separately: a quote that melts them into one line cannot be compared with any other.

The screens. Count them, and separate those that display from those that capture: a form, with its errors and its edge cases, costs several times a browsing screen.
The user account. Sign-up, login, forgotten password, account deletion — the last of these required by the stores as soon as there is sign-up. This block is almost always underestimated.
The server and the data. An app that only displays fixed content is cheap. As soon as it records anything, you need a database, an interface to administer it and a backup. This is often the first item on the quote.
Notifications. Technically simple, costly in settings: permissions to request, different behaviours on the two systems, and business logic to write to decide what to send and when.
Payment inside the app. If there is a purchase, the stores impose their own mechanism and take a commission. It is both a build and a share of your revenue.
Acceptance testing on real devices. Non-negotiable, and the first item trimmed from a tight quote — which is paid for in fixes after publication, at urgency rates.

3. What runs every year

A neglected website stays online. A neglected app becomes unusable, then disappears. That is the essential difference, and it is a financial one.

Developer account fees. Publishing requires an account on each store: an annual subscription on Apple's side, a one-off fee on Google's. Modest, but an unrenewed Apple subscription pulls the app from sale.
Forced updates. Every year, new versions of iOS and Android move the rules, and the stores require a build with recent tools before accepting an update. So you have to intervene even without changing anything in the app.
The server. Hosting, database, backups: a monthly cost that grows with usage.
The fixes. A crash does not show like a broken page: it shows in the store reviews, where it stays for months.
Watching the reviews. Nobody looks after them, and they are the first thing a future user reads.

Provision for these items over three years before signing. An app delivered with no budget for what follows is an app that will be pulled from the stores — sometimes before it has served.

4. The cost of the stores: refusal

It is an item absent from every quote, and it is real: publication is not a filing, it is a review. Both stores read the app and refuse for reasons often unrelated to development — an incomplete privacy policy, no way to find account deletion, test credentials that do not work, a permission explanation judged insufficient, a resemblance to a website with no value of its own.

Each refusal costs two things. Time: a fix, a new submission, a new wait. And a date: if the launch was announced, it slips. A project run with no margin on this point ends up paying for urgency over an administrative reason.

So ask any contractor who handles publication and who takes back up the refusals. The answer is worth a line on the quote.

5. The question to ask before paying

Many apps should never have been built, and the budget would have been better spent elsewhere. Three questions settle it honestly.

Is the usage repeated? You install an app for what you open often — ordering, tracking, clocking in, loyalty. For occasional browsing, a site on a phone does better, with no install to obtain.
Do you need the device? Notifications, camera, location, working offline, barcodes: if none of that is any use, the app brings nothing the web cannot do.
Who is going to install it? This is the point that sinks the most projects. Getting an install is harder than getting a visit. Without an already captive audience — regular customers, members, field teams — the app will stay empty, whatever its quality.

If the three answers are not clear-cut, start with the website: the page on what a website costs sets out that route. The app will come when the usage exists.

6. Paying for what follows, not for publication

If the spending is concentrated after the launch, then what you need to buy is not a build: it is a presence that lasts.

At nullbot, the app is described in conversation, like the website. You watch it run in an iOS and Android simulator before any publication — you can handle it and take screenshots of it. It can have its own database, it goes through an acceptance pass, the binary is produced for each target, and publishing to the App Store and Google Play is steered from the same place, with each store's status in front of you.

That is still not what we sell. What we sell is the following year: the team of agents that stays. It prepares the updates the stores demand, takes back up a review refusal, fixes what crashes, keeps the listings and their translations, watches the reviews. The app is not waiting for a maintenance budget that will never come — it is the team's ordinary work.

The spending stops being a project to fund and then refund. It becomes a monthly subscription, and publication is no longer the finish line.

7. Week 1, month 3, year 2

The three moments that separate the offers — and they are not the same as for a website, because the stores impose their own calendar.

Week 1. The app is published on both stores, its listings are filled in, a test account works for the review. A competent contractor knows how to do this.
Month 3. Three complaints concern the same screen, a two-star review is at the top, a system version has come out. The question becomes: who published the fix? A project delivered with no follow-up is already losing its users here.
Year 2. Both stores require a build with more recent tools, on pain of refusing any update. Without intervention, the app stays installed for those who have it, no longer installs anywhere, and eventually stops launching. That is the moment a redesign budget appears — for the same reason it will appear again.

8. The limits, said plainly

A highly specialised app remains bespoke development. Advanced image processing, hardware connected over Bluetooth, fine-grained mapping, a game: these are trades, and a classic development budget.
Store review cannot be guaranteed. No contractor can promise acceptance, nor a date. What can be promised is to take the case back up until it passes.
An app does not create its own audience. If nobody installs it, no team will change that. Reread section 5: it is the most economical decision in the project.
Anything that commits the company goes through an approval. Putting something on sale, a price change, a message sent to all users are submitted to you before they go out.

9. Frequently asked questions

Why not give an average price for a mobile app?

Because the gap between a browsing app and an app with accounts, payment and notifications is such that an average would tell you nothing. The items in section 2, costed for your own case, give a defensible order of magnitude. A single figure would mostly give false confidence when comparing two quotes.

Does a single app for iPhone and Android cost less?

Less than two separate builds, yes, and that is common practice. But the saving is not by half: fine-tuning, testing and each platform's peculiarities still have to be done on both sides, and the store listings have to be produced twice. Count a supplement over a single platform, not a free second one.

Do I need an Apple and a Google account in my own name?

It is strongly preferable, and it is a point to settle before signing. An app published under a contractor's account is hard to recover, and its review history does not transfer. Open the accounts in the company's name, even if you delegate access afterwards: it is a quarter of an hour at the start, and a complete deadlock later on.

What happens if I never update the app?

Three things, in this order. The stores first refuse your new versions because the build tools are too old. Then the app stops working properly on recent phones. Finally, an app long without an update can be withdrawn from sale. That is what separates an app from a website: inaction does not leave it in place, it deletes it.

Is my website enough instead of an app?

In most business cases, yes — and that holds true even when an app would be nice to have. A website works on every phone, requires no install, has no review to pass and no update forced on it every year. An app is justified when usage is repeated and you need something from the device. The three questions in section 5 settle it in a few minutes.