There is no honest public starting price for every mobile app. One client may need a small improvement to an existing product. Another may need customer accounts, a new backend, payments, staff tools and releases for both Android and iPhone. Calling both projects an app does not make the work comparable.
A useful quote should explain what will be designed, built, connected, tested and released. This guide shows where that work sits so a nontechnical buyer can understand a proposal without learning software terminology.
The budget starts with the job, not the screen count
A large app can be straightforward when it only shows information from a reliable existing system. A small looking app can be difficult when it takes payments, works without internet, protects private records and keeps several systems in agreement.
Describe the useful result in one sentence. For example, a customer books a service and pays a deposit, or a field worker records a completed visit when the signal is poor. This gives a developer something real to assess.
A smaller scope still needs a complete result
A focused release works best when it has one main user and one job that matters. It might include sign in, a small account area, a list or catalogue, one form or booking journey, basic notifications and a simple admin view.
The aim is not to remove essential testing or release work. It is to finish one useful journey before adding secondary ideas. This makes the proposal easier to understand and gives real users something meaningful to review.
- One main customer or staff journey
- A limited set of account and admin actions
- Few device features
- An existing data source or a simple new backend
- Clear testing and release responsibility
Supporting both platforms adds more than another store listing
The app must be checked on different screen sizes, operating system versions and device behaviours. Shared code can reduce repeated work, but Android and iPhone still have their own testing and release processes.
The proposal should say which platforms are included, which devices will be tested and whether any feature needs separate platform work. Without that detail, two quotes may appear similar while covering very different responsibilities.
What are you actually asking a developer to deliver?
These may all be described as an app, but they are different pieces of work. Make sure every proposal describes the same result.
Swipe sideways to compare every column.
| Starting point | What it delivers | What changes the quote |
|---|---|---|
| Clickable prototype | Designed screens that people can tap through for feedback | Research, number of journeys and the detail needed in the design |
| Focused first release | One complete customer or staff action in a working app | Login, existing data, device features, testing and store release |
| Connected business app | Android and iPhone experiences supported by accounts and admin tools | Backend work, user roles, integrations, notifications and business rules |
| Operational mobile product | A product used for important daily customer or staff work | Offline use, payments, live data, messaging, security, scale and ongoing support |
The work grows when the app becomes part of daily operations
Several user types may need different permissions. Money or private information may need careful handling. Live location, chat and offline work create many situations that must be designed and tested, including what happens when a connection fails.
A marketplace is a good example. The customer journey is only one part. The business may also need seller accounts, approvals, payments, refunds, complaints, reports, support tools and ways to handle misuse. Those systems are part of the product even when customers never see most of them.
- A new backend and detailed admin tools
- Several account types and permission rules
- Payments, refunds or subscriptions
- Offline work and safe data synchronisation
- Live location, messaging or time sensitive updates
- Special privacy, security or compliance requirements
Android is not automatically cheaper than iPhone
The larger cost is usually the product itself: accounts, data, business rules, payments, testing and support. A simple Android app can require less work than a complex iPhone app, and the reverse is also true.
Building for one platform reduces the first test and release workload. Building for both with shared code can be efficient when the app uses normal screens and common device features. If it depends heavily on camera processing, background activity, Bluetooth or other device behaviour, some work may still need to be handled separately.
The backend can require more work than the screens
The backend stores accounts, bookings, orders and permissions. It also decides what each person is allowed to see or change. An API is simply the safe doorway the mobile app uses to read and update that information.
If your website or business software already has a reliable doorway, the mobile work can stay focused. If the data is spread across spreadsheets, inboxes and old systems, the project may first need a database, admin area and clear connection rules.
Where the work sits in a booking app
Imagine a service business that wants customers to create an account, choose a service, book a time, pay a deposit and receive reminders. Staff also need an admin area to manage availability and bookings. The app will be available on Android and iPhone.
The visible booking screens are only one part of the proposal. The developer also needs to understand the work listed below. An existing booking system may reduce some of it, while unusual pricing rules or several staff roles may add more.
- Confirm how customers, staff and services are organised
- Design the customer journey and the staff admin view
- Build or connect accounts, availability, bookings and deposits
- Create the Android and iPhone experience
- Test failed payments, changed bookings and missed connections
- Prepare the store listings and release the app
- Monitor problems and improve the journey after launch
Running costs may sit outside the first build quote
Ask which accounts and services the business will pay for directly. Developer accounts, hosting, messages, maps, payment processing and monitoring may be charged by other providers. They should still be visible in the plan before work begins.
- Cloud hosting, file storage and backups
- Text messages, email, maps, video or identity services
- Payment processing charges
- Privacy advice, terms and specialist compliance review
- Crash monitoring, security updates and new store releases
- Customer support and product improvements after launch
Compare the work inside the quote, not only the total
One quote may include backend work, testing and store release while another covers only the visible screens. Ask every supplier to show the same information in plain language.
- Which customer actions are complete in the first release
- Whether Android, iPhone or both are included
- Who builds the backend and admin area
- Which external services are excluded
- Which devices and failure situations will be tested
- Who owns the store accounts, source code and designs
- What happens after launch and how support is agreed
Reduce scope without weakening the main journey
Remove secondary features, not the work that makes the main action reliable. A smaller app that finishes one important job is more useful than a large app where every feature is incomplete.
Use an existing payment, booking or account service when it genuinely fits. Choose one main user type and give feedback on working versions quickly. Chat, advanced reports, offline work and several permission levels can wait unless they are essential to the result.
Services Behind the Quote
Mobile App Development
Android and iOS apps for customer actions, booking, tracking, staff workflows, and app supported systems.
Continue planning your app
Native or shared mobile development
Understand when shared code is practical and when Android or iPhone needs separate work.
Mobile app maintenance costs
Plan for operating system updates, monitoring, store releases and product support after launch.
Ask for a proposal that matches the real job
A useful first estimate does not need every screen to be decided. It does need the main user, the action they must complete, the data behind that action, the platforms you need and any difficult device or business rules.
Start with that information and ask for a clear first release. You will receive a more useful proposal than you would from a long wish list or a public price based only on screen count.
Sources and Further Reading
- Apple Developer Program. Official information about the account used to distribute iPhone apps.
- Google Play Console registration. Official information about the account used to distribute Android apps.
- Apple App Review Guidelines
- Android core app quality guidance
Editorial note: ScriptEvolve does not publish a universal starting amount because a small change to an existing product and a complete new app are different pieces of work. The proposal should match the exact result, systems and release responsibility.