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 important journey, it explains the data, permission checks, integrations, failure behavior and release work. The estimate should also state the assumptions that would change the price. “An app with login and payments” leaves too much of that work undefined.

Begin with a short scope statement: who is doing what, what system records the result, and what evidence proves it happened. A customer requesting an appointment is different from paying for one. Paying a business is different from a marketplace that distributes money to several providers. Similar interfaces can sit on very different systems.

Platforms, roles and integrations deserve separate questions. Does the product need device capabilities, 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 is the team first discovering how an existing system works?

Operational work belongs in the scope too. Somebody needs to support account recovery, answer a failed-job alert, manage an import and resolve a billing exception. If the customer journey depends on staff work, define the administrative interface or the documented manual step. Otherwise, a “finished” app can still leave the business unable to operate it.

Cut optional journeys before cutting the integrity of the core journey. A first version can offer fewer account types, a smaller catalog or a staff-assisted exception process. It still needs to protect the information it holds and tell users accurately what happened. Removing a payment failure message does not remove the possibility of a payment failure.

Write a launch requirement and a later idea beside each feature. Keep the requirement when the product cannot deliver its first useful outcome without it. Defer the idea when you can learn from real usage before building it. Ask the team to explain the consequences of each cut so a small first version remains coherent.

Ask each vendor to describe the same customer journeys and demonstrate the same acceptance cases. Then compare what they include: design, implementation, tests, release support, data migration, accessibility work, documentation and support. A fixed price is useful only when the boundaries behind it are understandable.

Read the exclusions with the same attention as the feature list. Find out who supplies content and accounts, what happens when an outside provider changes its behavior, and how extra work is approved. Ask whether bug fixes are defined against agreed acceptance criteria and how the handover distinguishes an unresolved 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. Submission also requires product information, privacy and support materials, testing and review access appropriate to the app. A developer cannot turn an account fee into a guarantee of approval. Ask which submission and review-response tasks are included in the proposal.

AI tools can help create code and prototypes, but the existence of generated code does not establish how much production work remains. Ask to see the application perform the core task with realistic data, correct permissions and a repeatable deployment. That demonstration gives you more useful information than the number of prompts or files produced.

If you already have an AI-built prototype, price assessment and repair separately from adding features. The result may be worth keeping, may need a bounded repair or may require a larger change. The decision should follow the implementation you actually have. It should not follow a promise that every generated app is either production-ready or worthless.