How much does it cost to build an app in 2026?

A useful estimate names the user, the task and the completed result. For each main journey, it covers the data, the permission checks, the integrations, what happens when something fails and the release work. It also lists the assumptions that would change the price. “An app with login and payments” leaves most of that undefined.

Start with a short scope statement: who does what, which system records the result, and what shows that it happened. A customer who requests an appointment is doing something different from one who pays for it. Paying one business is different again from a marketplace that splits money between several providers. The screens can look alike while the systems behind them have little in common.

Platforms, roles and integrations each need their own question. Does the product need something only a phone can do, or can the first useful version run in a browser? Can every customer see the same information, or does the app isolate records by person or organization? Does an integration have a supported API, or does the team first have to work out how an existing system behaves?

Put the day-to-day work in the scope too. Somebody has to help with account recovery, answer a failed-job alert, run an import and sort out a billing exception. If the customer journey depends on staff work, define the admin screen or write down the manual step. Otherwise you can end up with a “finished” app that the business cannot run.

Cut optional journeys before you cut into the integrity of the core journey. A first version can have fewer account types, a smaller catalog, or staff handling the exceptions by hand. It still has to protect the information it holds and tell users accurately what happened. If you remove the payment failure message, payments will still fail and the customer will not be told.

Mark each feature as a launch requirement or a later idea. It is a requirement if the product cannot deliver its first useful result without it. It is a later idea if you can learn from real usage before you build it. Ask the team what each cut breaks, so the small first version still works as a whole.

Ask each vendor to describe the same customer journeys and demonstrate the same acceptance cases. Then compare what each one includes: design, implementation, tests, release support, data migration, accessibility work, documentation and support. A fixed price only helps if you can see where the work it covers starts and stops.

Read the exclusions as carefully as the feature list. Find out who supplies content and accounts, what happens when an outside provider changes how it works, and how extra work gets approved. Ask whether bug fixes are measured against agreed acceptance criteria, and how the handover tells an unfixed defect from a new request.

Apple currently lists its Developer Program at US$99 per membership year, with regional pricing and eligible waivers. Google lists a US$25 one-time Play Console registration fee. These are provider account fees checked on November 7, 2026, not the cost of building, testing or submitting your application.

Your business should control the store accounts. To submit, you also need product information, privacy and support materials, testing, and review access that suits the app. Paying the account fee does not guarantee approval, whoever your developer is. Ask which submission and review-response tasks the proposal includes.

AI tools can help you create code and prototypes, but having generated code does not tell you how much production work is left. Ask to see the app do its core task with realistic data, correct permissions and a repeatable deployment. That demonstration tells you more than a count of the prompts or files produced.

If you already have an AI-built prototype, price the assessment and repair separately from new features. What you have may be worth keeping as it is, may need a limited repair, or may need a larger change. Base that decision on the code you have. Be wary of anyone who says every generated app is production-ready, or that every one is worthless.