How much does an app cost: what drives the price

The manager asked for an app quote for the first time and came back with three proposals that seem to describe different projects. One covers only the phone screens. Another includes an API, an admin panel and store publishing. The third delivers a PWA installable from a link and leaves the stores out. The numbers diverge, and nobody can explain the gap in one sentence.

This article shows what goes into an app's price, why quotes for the "same" request differ so much and what to bring so proposals become comparable. In the middle you will find a ready checklist. If you are still choosing between PWA and native, start with PWA vs native app. If you want to see how a project runs from discovery to production, read custom software project.

What goes into the price of an app?

The price of an app covers the work of turning a process or a product into software people use on a phone, including what has to exist behind that screen. In most projects the screen is only one part. There is an API, a database, an admin panel, access rules, publishing and a period of fixes after launch.

On our mobile apps page we state this explicitly: an app almost never stands alone. It needs an API, a database and a panel for the team that manages content and users. When the path is the store, setup of accounts, listing copy and screenshots and follow-up on review also come in. That page says Apple and Google reviews usually take from one to a few days, and that the first release needs slack because the store can come back with requirements.

There are small public fees many teams discover late. The Apple Developer Program charges 99 US dollars per year to publish on the App Store. Google Play charges a one-time 25 US dollar registration fee. Those amounts do not set the project price, but they belong in the budget of anyone going to the stores.

Why do quotes for the same app differ so much?

Quotes diverge because each vendor fills the gaps in the request with different assumptions. If the brief only says "inspection app for the team", one side assumes a simple PWA form, another assumes native apps in both stores with offline photos and a metrics panel. Both are answering the text they received. They are pricing different scopes.

Three gaps explain most of the difference:

1. Platform: PWA, native iOS, native Android or both native apps. The article on PWA vs native app shows when each path makes sense.
2. Back end: the app alone, or the app plus API, plus panel, plus login and roles.
3. Boundary of the first version: what ships now and what is written as a later phase.

Process detail also weighs. People who work on a quay, on board or at a gatehouse know exceptions a screen list hides: shared devices, night shifts, areas without signal, contractors without a record. Without those exceptions in the brief, each proposal invents a scenario.

In the health app we built, the choice for native came from concrete requirements: store subscriptions, Sign in with Apple and daily use on iOS and Android. We used React Native with Expo and the same Ruby on Rails back end. In offshore passenger transport, the path was a PWA, because the internal team receives the system by link and updates without going through a store.

What weighs most and what barely changes the price?

What weighs most is first-version scope, number of platforms, API and panel complexity, integrations and offline work. What barely changes the price on its own is the store registration fee, the choice between two similar libraries and the home-screen icon.

The table does not replace discovery. It helps you read a proposal: if the number looks low and the left column is full of fuzzy items, the risk sits in what was left out. If the number looks high and the proposal details integrations, offline use and a panel, compare the content, not only the bottom line.

Market salary does not set a project price by itself. Robert Half publishes a Brazil-wide midpoint of R$ 11,700 for a mid-level mobile developer (entry salary for that role listing). That speaks to the cost of keeping people allocated, not to the price of a delivered app. A project mixes design, development, testing, publishing and follow-up; one salary figure does not close that account.

What should you bring to request a comparable quote?

What makes quotes comparable is the same set of decisions answered before you ask. Without that, each vendor fills the blanks with the hypothesis they know best, and you compare apples to oranges.

Use the checklist below with people who know the routine (not only with whoever approves the purchase). Bring the answers in writing. Ask each proposal to say what is in, what is out and which assumptions were used when something stayed open.

After you tick the items, reread the "what is out" column. That is where honest proposals separate from the ones that promise everything in a single number. If you still need to choose between PWA and native, answer the checklist in PWA vs native app first and only then ask for price.

How do you compare proposals without getting lost in the numbers?

To compare proposals, align the scope first and only then look at the amount. Ask every vendor for the same grid: platforms, API and panel, integrations, offline, publishing, what is out and how support works after launch.

A practical grid:

1. What the first version delivers, in features someone can test.
2. Which devices and operating systems that runs on on launch day.
3. Whether the API and panel are included or are another project.
4. Which integrations are in the price and which depend on another team or contract.
5. How the app behaves without signal, if that matters to the operation.
6. Who publishes to the stores or distributes the PWA, and who replies to review.
7. What happens in the first weeks after launch: fixes, support channel, new versions.
8. What the proposal declares as out of scope.

Be careful comparing only by "weeks on a timeline" when the brief is still vague. A short timeline with an open scope often hides a second negotiation halfway through. The article on a custom software project explains why a first version in real use is a better signal than a promise of a complete system at the end.

Also compare who takes part on your side. A proposal that assumes the vendor invents the process alone will bill rework later, when operations points out the real exceptions.

What if the app is internal only, iOS only, or must work offline?

If the app is internal only, a PWA often cuts distribution and maintenance cost, because it updates for everyone at once and skips store review. The team gets a link or a QR code. In our operations systems this is the most common path: a pilot records a trip and a crew member runs a checklist on board without going through the App Store. The offshore passenger transport and vessel inspection and maintenance cases follow that line.

If you only need iOS at first, you can publish one platform first and leave the second for a later phase, as long as the API is born ready for both. Publishing to one store reduces review and listing work, but it does not remove the back end. The panel and the rules still exist.

If the app must work without signal, offline use belongs in scope from discovery. You need to say what stays on the device, for how long, and what happens when two people edit the same record while disconnected. That design weighs on price in any technology. In the vessel inspection case, a finding recorded on board shows up ashore when the connection returns; that rule has to be agreed before development.

Personal data changes the care required, even when the app is internal. Brazil's LGPD (Law 13.709/2018), in article 46, requires technical and administrative security measures to protect personal data, observed from product design onward. In practice, access roles, logs of sensitive actions and a definition of what the device stores offline belong in the budget together with the screens.

When is an app not the path (yet)?

An app is not the path when the process still has no owner and no clear rule. If every team works differently and nobody can describe the right flow, the phone only moves the mess into everyone's pocket. The first job is to write the process with the people who run it.

It is also worth waiting when what is missing is the system behind the phone. A mobile form without a shared record, without permissions and without reports becomes an island of data. In that case the earlier step is the custom web system that holds rules and information; the app becomes one of its screens.

Off-the-shelf software fits better when the process is generic (for example, simple queues like any other company) and you accept adapting the operation to the product. Then the price of a custom app is usually surplus.

If your team can already describe the problem, the users and the first version, boosting.tech is a custom software company that builds apps and the back end they need. The diagnostic conversation has no cost: we align scope, platforms and what is out, and only then talk about a proposal. Details are on mobile apps.