How much does an app cost:
from idea to further development

How much a mobile app costs at iSEO.pro

Product prototype from $2,360, complete app from $17,670, further development of an existing product from $11,780. These are starting prices for an agreed scope. The specific estimate depends on features, platforms, data, integrations and release requirements.

Do not add these three amounts together automatically. If product planning is already included in the app estimate, do not count it again as a separate prototype. When a prototype is commissioned first as a standalone project, agree which outputs will be used at the next stage and how that affects the estimate.

A “complete app” price needs a breakdown of the platforms, backend, admin interface, integrations and checks included. A package name alone does not mean unlimited features, ongoing support or guaranteed app store approval.

Estimate workflows, not just screens

Two catalog apps can look similar yet cost different amounts. In one, users see a standard price and send an enquiry. In the other, they get individual terms, stock from several warehouses, reservations, payment and documents. A screen list does not capture all this logic.

For each feature, describe its starting point, outcome and exceptions. “Authentication” might mean a simple code-based login or inviting employees with roles, blocking and account recovery. “Checkout” might mean an enquiry form or calculating complex terms with payment.

Identify the essential user action and the features it depends on. Reduce the first release’s scope while preserving a complete, useful workflow. An empty interface with a promise to “add everything later” cannot test demand for the product.

What the prototype stage pays for

A prototype helps agree navigation, transitions and content before coding. Deliverables may include a workflow map, interactive screens, a first-release feature list and a refined development estimate. Define those deliverables in the brief in advance.

Test the prototype with people from the target audience: can they complete the main task without the creator’s explanations? Record where they stop, unclear labels and missing actions. Correcting the path in a mockup is usually easier than changing a finished system.

A clickable prototype alone does not prove that integrations, payments, offline operation or synchronization work. A technically complex feature needs a separate trial, such as reading from an existing API or communicating with a device. State which risk each deliverable tests.

Agree on handing over the editable design, components, workflows and estimating assumptions. The next team should understand what is agreed, what has been tested and which questions remain open.

iOS, Android and the choice of technology

Start by identifying your audience’s devices and the essential features. An internal tool for a known fleet of company devices may need only one platform. For a public customer service, base the decision on actual users, not the client’s own phone.

Native development uses tools specific to a platform. A cross-platform approach allows part of the code to be shared. The savings depend on the interface, device features, libraries and quality requirements; there is no universal cost multiplier for every project.

• Test cameras, location services, Bluetooth, notifications and background tasks on the target devices.
• Confirm the supported operating system versions and the availability of required libraries.
• Allow for testing on each platform, even with a shared codebase.
• Compare both launch work and the team’s ongoing maintenance responsibilities.

If a usable mobile website can meet the need, compare that option too. An app should be justified by recurring workflows, device capabilities or other specific advantages. Architecture can be discussed when choosing your product’s technology.

What often lies beyond the screen

Users see a screen, but permissions, the catalog, orders and history usually depend on the backend. The estimate should make clear what already exists, what needs modification and what will be built from scratch. Clarify who manages the data and whether an administration interface is needed.

For each integration, check the documentation, test environment, request limits and system owner. Having a CRM does not mean it is ready to supply individual prices to a mobile app. This work may require several teams.

In our illustrative catalog, the enquiry must reach the right manager with the SKU and quantity. If this relies on CRM integration, test the entire journey, including repeated taps and temporary system outages.

An example budget breakdown

The following illustrative estimate is for an app with a catalog and enquiry submission. It shows the cost structure; it is not a price list for every product with these screens. The actual scope and cost are confirmed after discovery.

Ask for a breakdown of broad line items: tasks, estimated time, the person’s role and the deliverable. Hours help compare assumptions but do not guarantee accuracy on their own. Investigate unknown integrations first instead of hiding the risk in a round figure.

List exclusions and conditions separately: platform fees, paid services, server infrastructure, catalog content, promotion and future features. Clarify whether taxes are included. Different teams’ totals should cover the same scope and period.

If a contingency budget is needed, link it to specific risks. It is not unrestricted funding for any new idea: agree separately on how the reserve is used and how the release scope changes.

Store fees and release preparation

A developer account fee and release preparation are separate costs. Publishing requires builds, an app listing, assets, data disclosures, testing and responses to store feedback. Establish who owns the account and how the team will access it for future updates.

As of this article’s update, Apple Developer Program lists an annual membership fee of USD 99, or the available local-currency equivalent. The Google Play Console guide lists a one-time registration fee of USD 25. RuStore states that hosting free and paid apps is not charged.

Before paying, check the current terms, registration availability and payment method for your account and country. These amounts do not include sales commissions or other monetization conditions, which must be assessed separately for the specific product.

Agree on which stores are included and how review feedback will be handled. New personal Google Play accounts have additional testing requirements; check the applicable rules in the official guide. A contractor’s promise to “publish on any day” cannot determine the platform’s decision or review time.

Calculate operating costs

After release, costs remain for the server, database, backups, monitoring, third-party services and support. Plan new features separately. Fixing a defect in agreed work under warranty, adapting to an external API change and adding a new user workflow may fall under different obligations.

Illustrative example: launch — $28,800; infrastructure and external services — $300 per month; agreed support — $720 per month. Launch plus twelve months of operation, in USD: 28,800 + (300 + 720) × 12 = $41,040. This excludes store fees, promotion, your own team and new features.

A fixed, mandatory support percentage of development cost is not a useful universal rule: a small app may need a complex integration, while a large, stable catalog may need a different support arrangement. Clarify service hours, response urgency, included tasks and charges for work beyond the allowance.

At iSEO.pro, further development of an existing product starts at $11,780 for an agreed scope. This starting price is for a development project; ongoing support terms are agreed separately.

Compare normal and peak loads. For SMS, maps, file storage and other paid services, usage units and limits matter. Record who can see the costs and who is notified when a limit is approaching.

How to assess developers’ proposals

Give each team the same list of workflows, platforms and integrations. Ask them to identify included work, assumptions, exclusions and questions. If one estimates only the interface and another the whole product, the price difference does not show who works more efficiently.

1. Compare the first version’s features and acceptance criteria.
2. Check the backend, administration interface and integrations.
3. Confirm the device list and test scenarios.
4. Compare handover of code, design files, documentation and access.
5. Calculate operating costs over the same period.
6. Document how new requirements will be estimated.

A fixed price works well when the scope is clear. Time-based billing allows priorities to change but requires transparent reporting and budget control. Both approaches need interim demonstrations and acceptance of deliverables, not just a final handover date.

Before choosing a provider, discuss whether another team could continue the project. Source code without build instructions, dependency details and the necessary access may not be enough to release an update.

Where costs can be reduced

Validate demand and the main user journey before complex development. Defer secondary roles, rare scenarios and decorative effects. Use existing systems when they truly fit and offer a working integration interface.

Agree on one clearly defined release and a list of later improvements. This helps prevent continual scope expansion. If a feature matters but its cost is unknown, run a technical trial before committing to it in the overall plan.

Testing critical operations, access control, data recovery and project handover must match the actual risks. Removing them entirely reduces the initial estimate but increases the likelihood of costs after release.

Also account for user acquisition: publishing alone does not create a returning audience. Discuss promotion and product analytics separately, linking them where appropriate to performance marketing and measurable actions within the app.

App budget checklist

Frequently asked questions about app costs