What drives the cost of a business app, and how a cap works

The cost of a business app follows a handful of drivers: how many user journeys it covers and for how many kinds of user, how ready the design and the API are, what it integrates with, what has to work without a signal, how much testing your organisation needs, and the work of releasing it to two stores and keeping it there. The number of screens, the figure most enquiries lead with, is a poor proxy for every one of them.

That is why no serious studio prices an app from one email. Two apps described in a sentence each can differ several times over in effort once those drivers are known. What you can get from a first exchange is a list of the drivers that matter for your app, what it takes to settle each one, and a way of working that keeps the estimate under control once work starts.

This article walks through the drivers from the builder's side, what you can prepare to narrow them, what a fixed price hides, and how an estimate with a cap works in practice. It gives no price range on purpose. A range without the drivers behind it is a guess dressed as an answer, and our prices are agreed per project.

Why the number of screens misleads

A screen is where the work becomes visible, not where it happens. A list of today's visits for a field technician is a small job if the API returns exactly those visits, sorted and paged. It is a much larger one if the API returns everything and the app has to filter, cache and reconcile. The screen looks the same in both cases.

What moves an estimate is the number of distinct things a user can do, the number of user types with different rights, the state of the systems the app connects to, and everything that has to hold at the edges: no signal, an old version still installed, a four-year-old phone, a reviewer at Apple with a question. The table below is how we read a brief.

What drives the cost

Scope: journeys and roles

Count what people can do, not what they can see. A technician who opens a visit, fills a checklist, takes two readings, adds photos, collects a signature and submits is one journey with six steps, and each step has a failure case: the photo upload that times out, the signature the customer refuses, the visit dispatch cancelled meanwhile. The cost sits in those cases. A second role, say a supervisor who can reopen a submitted visit, is not one more screen; it is a second set of rights the API must enforce and the app must respect everywhere.

The cheapest decision in any app project is the one that keeps a journey out of the first release. The proposal brief article shows how to write that down.

Platforms: one codebase, three release paths

We build iOS and Android from one React Native codebase, and web apps with Next.js. The shared code covers most of a business app. What stays separate is the part you cannot share: each platform's build, signing, store review and testing on real devices, and the native pieces, such as a payment or scanning SDK, that come as two libraries with two sets of quirks. A web app for the office, a common part of B2B products, is a third surface with its own hosting and its own tests. The article on React Native for business apps separates what one codebase removes from what it does not.

Backend and integrations: where most of the spread sits

Of all the drivers, the state of the API explains most of the difference between two estimates for similar apps. An API that already serves the journeys, with sign-in and permissions enforced on the server and a test environment with realistic data, lets the app work start on the app. An API that returns everything and trusts the client to sort it out moves work into the app that belongs on the server, and that work is fragile.

We build on the API you have. When it needs to change, we work with the person on your side who can change it. Backend development is not a standard service; for a new product, what it needs on the server side is agreed as part of the scope. The article on what your API needs before we build a mobile app lists the checks.

Integrations are the second source of spread. Each outside service, a payment provider, an identity verification vendor, a mapping or e-signature SDK, arrives with its own account, contract, test mode and often its own review before it may go live, and the account should be in your company's name from the start. Before Tolaron I was senior mobile developer and team lead at a UK FCA-authorised payment institution for five years, and there the integrations, not the screens, set the pace of every release.

Design: three starting states

Design readiness comes in three states, and the estimate is different for each. Defined: the flows are designed and agreed, perhaps already in use on your website, and the app follows a design system that exists. Sketched: the main flow is clear, the brand is known, the screens are not drawn. Open: the product itself is still being decided. An app brand guide written for print and the web still leaves the app's components, states and motion to be designed, which is normal and worth saying in the scope.

Discovery starts with a clear picture of the project's scope, and we can show you, free of charge as an MVP, roughly what the app could look like. That preview is not the design work; it gives both sides the same picture before the scope is written.

Security and compliance: requirements, not a label

The security work in a business app is concrete: encrypted storage on the device, session rules and biometric sign-in, checks for rooted or jailbroken devices where your policy wants them, an audit trail of who did what, and the privacy prompts and disclosures each platform requires. Each item is a line in the scope with an owner. What adds cost is not any one of them but a requirement that arrives late, after the flows are built.

Whether GDPR, DORA or sector rules apply to your app, and what they require, is your organisation's call with its advisers. We build to the requirements you set, keep each one visible in the scope, and never present a release as compliant on your behalf. Two of the platform-level requirements have their own articles: the European Accessibility Act and the EU tracking prompt from iOS 27.2.

Testing on real devices

Testing is where estimates most often go quiet, because it is easy to assume. A business app needs the devices your staff actually carry, not the newest ones, the OS versions still in use, data in the shapes your systems really produce, and the awkward paths: the interrupted upload, the expired session, the version that is two releases old. Then an acceptance round on your side, by named people, against the acceptance criteria written into the scope. Each of those is a cost you can see in advance if the scope names it.

Distribution: two stores, sometimes a private channel

A public app is released twice. Both stores enrol your company, not the supplier, and both verify it: the Apple Developer Program costs USD 99 a year and asks an organisation for a D-U-N-S number and someone with authority to sign; a Google Play developer account is a one-off USD 25, with its own organisation verification. The fees are small; the setup time is the real cost, so start it early and keep the accounts in your name, as who owns your app explains.

Each release then goes through each store's review, with listings and screenshots in every language you support and for each device class. An app for your own staff may not belong in the public stores at all; both platforms offer private distribution to an organisation's devices, which has its own setup and rules, and that choice belongs in the scope.

After launch

The app keeps costing something after the release, and it is better to know the shape of it now. Operating systems change every year, store rules move, old versions stay installed on someone's phone and the API has to keep serving them. Google Play's target API requirement is one example: since 31 August 2026, new apps and updates must target Android 16. Monitoring, alerts and who decides on a fix are agreed for your project, not assumed. The app-or-mobile-website article goes through the running costs in more detail.

What you can prepare

Each of these narrows the estimate before anyone writes it:

• The one journey the first release must complete, and the roles that use it.
• The state of your API: what it serves today, who can change it, whether a test environment with realistic data exists.
• The list of outside services and who owns each account.
• What already exists in design: brand guide, web design system, sketches.
• Your security and review requirements, with the person who signs them off.
• The devices your users hold, and whether they are managed company phones.
• Who accepts the work, and who owns the store accounts.

Write unknowns down as unknowns. "We are not sure whether the API supports this" is more useful than a guess, because it names a check both sides can do before relying on the estimate.

What a fixed price hides

A fixed price feels safe, and for a precisely specified scope it can be. For a first release, where the drivers above are still being discovered, a fixed price has to pay for the unknowns somehow. In practice it does so in three ways: a risk buffer you pay whether or not the risk arrives; change friction, where every discovery turns into a negotiation about what the price included; and an incentive to resolve anything the specification left silent in the cheapest way, not the right one.

The question to ask a studio is not "what is your price" but "what happens when something changes". The answer tells you more about the final cost than the number does.

How an estimate with a cap works

Our model is the one on the mobile app development page, and it has four parts:

1. The scope in writing. Deliverables, exclusions, responsibilities, dependencies on your side, acceptance criteria.
2. An estimate and a cap. The estimate is our reading of the scope. The cap is the approved limit: the most you can be billed without a new decision from you.
3. Actual work billed under the cap. We bill the time we actually work. If the work comes in under the estimate, you pay less, not the estimate.
4. Approval before any increase. When something changes, you decide before we spend more.

Three words that are easy to blur: an estimate is what we expect the scope to take; the cap is the approved limit you have agreed to; the commitment is what the written scope and the acceptance criteria say we deliver. The cap is a limit on what you pay, not a guarantee that every line of the scope fits beneath it. If a driver turns out larger than the scope assumed, say an API gap nobody knew about, you decide what gives, the item, the cap or the release date, before the money moves.

A fictional example

This example is fictional and describes no client engagement. It reuses the company from our proposal brief article.

Northline Services, a fictional maintenance company, agrees a first release: the completed-visit journey for its technicians on iOS and Android, working offline, with photos and a customer signature, built on the existing dispatch API. The written scope lists the journey step by step, the excluded items, the test API Northline will provide, and Petra, its backend lead, as the owner of API changes. The estimate is written, and the cap is set above it.

Two things change during the work.

A change request. Dispatch asks whether technicians could draw on photos to mark a fault. We size it: it touches the photo flow and the offline sync rule, and it would take the work past the cap. Northline has three choices: raise the cap, trade the feature for something in the scope, or defer it. It defers it to the second release. The cap is unchanged, and the change request is recorded with its sizing, so release two starts from a known number.

A discovery. The API turns out to have no paging on the visits endpoint. The scope assumed it did. Petra adds it on the server, the workaround the app would have needed is struck out, and the estimate goes down. The cap stays where it was; the actual work billed under it is lower.

Nothing in either case needed a renegotiation, because the scope had already said who decides and what happens when the estimate moves.

Next step

If you are comparing studios, ask each one the same question: what drives the cost of our app, and what happens when something changes. For our answer on your app, a short summary is enough to start: the journey, the state of your API, the outside services and your constraints, sent through the contact page. The mobile app development page describes how we scope a project and what we need from you.

Sources

• Apple Developer Program: Enrollment (membership fee of USD 99 a year; organisation requirements including a D-U-N-S number)
• Google Play Console Help: How to register for a Google Play Developer account (one-time registration fee of USD 25)
• Android Developers: Meet Google Play's target API level requirement (new apps and updates target Android 16 from 31 August 2026)

All sources were checked on 10 October 2026.