Having decided to build a mobile app, it is necessary to properly assess your project. How much will it cost? How long will it take to build? A properly done estimation can provide accurate answers to these questions. Read on to find out how to estimate mobile app development, what you’ll need to do beforehand and what are commonly used price models among developers.
What affects the cost
The price of building an app depends highly on its functionality and the wages of those who are going to build it. Every feature takes a number of hours to program, and the more complex the app, the higher will be the price of building it and maintaining it after release. For more insights on why one app costs $10,000 and the other $100,000 read our article Mobile App Development: How Much Does It Cost?
Every feature of an app has a more or less fixed price, which depends on the number of hours it takes to program it. The more complex the feature, the more expensive it is going to be.
- Push notifications with links to specific app’s screens: $1,000–1,500 (25–30 hours).
- Text messenger and media sharing: $6,500–7,000 (160–170 hours).
- Integration with Apple Pay and Google Pay. $1,000–3,200 (25–80 hours).
If you plan to develop an app specifically for one platform, native development (Kotin for Android and Swift for iOS) is the best choice in terms of performance, stability and price. However, if you want your app to be present in both Google Play and Apple Store, consider building the app with a cross-platform framework, such as Flutter, React Native, Xamarin and others. Building a cross-platform app costs slightly higher than a native one (for example, in the US cross-platform developers earn about 10% more than their colleagues working with native languages), but you can use one set of code across both platforms, which results in 30–40% savings, compared to building two separate apps.
Every app requires updates to maintain complete compatibility with new devices and OSes, as well as fixing bugs (there are always some). Usually, these expenses amount to about 15% of the initial development cost per year.
Also, since almost every app stores user data, you will have to rent a secure server or cloud storage. The annual bill on renting a server’s space starts at $1500 and depends on the amount of data and number of your users.
Development team size
How many people develop your app should be determined according to the project complexity. You can find out more on who you’ll need on the development team in our dedicated article. Generally, a common setup includes:
- 2 developers (iOS and Android or cross-platform).
- QA (Quality Assurance) Engineer reviews all specifications and technical documents, as well as creates and plans all testing activities.
- Backend developer oversees data storage, payment systems and logic of app operation.
- UX/UI Designer creates a user-friendly interface for the app.
- Project-manager manages the development process and communicates directly with the client.
The geographical location of the team plays an important role in the development costs. For example, rates of software developers in North America are usually over $100 per hour, while developers in Western Europe provide code of the same quality for half of that price. When looking for developers, consider hiring an offshore development company or freelancers, because it can dramatically change the final price of the app. To learn more about talent acquisition read our article on where to hire developers.
Before estimating mobile app development, you’ll need to review all ideas and concepts and turn them into a detailed technical specification. The more detailed it is, the easier it will be to assess the costs. Software requirements specification usually include:
This part briefly describes the product and the app’s concept. A list of all app features is made along with a list of types users, their roles and classes. An overview also includes information on hardware and software requirements of the app, design & implementation constraints and a list of user documents to be released.
This section contains a detailed description of all app’s features, which contains: purpose, how a feature works (what triggers it, what it does), priority of implementation and use cases.
This part focuses on all types of interfaces of the app.
- Screens (user interfaces). Prototypes and descriptions of each app’s screen.
- Software Interfaces. Specifications of APIs, operating systems, database, third-party software.
- Hardware interfaces. Technical characteristics of how the app interacts with the device’s hardware. How it can be controlled via physical controls, what communication protocols are used and differences depending on a device model.
- Communication interfaces. Descriptions of communication features of the app (email, browser, messaging) and server exchange protocols. Configuration of the app’s communication with an external server.
- Other parameters and their specifications. Usage of geographic data, push notifications, in-app purchases, data security, performance measurement.
When you have the technical specification on hand, it’s time for estimation. To be accurate, the process should involve several stages, each of them clarifying development requirements more and more.
Stage 1. Breakdown
First, the provided technical specifications are decomposed into small and easily estimated parts of the app. Usually, the breakdown is done by screens or by functions.
By screens. A wireframe of every screen gets analyzed for present functions (login, record audio) and UI elements (buttons, text fields).
By functions. Every function of the app is analyzed: how a function works, its design in the UI and on what screens it is present.
Then, all features or screens are sorted by priority: must-have items, serving the app’s main purpose; ‘cool to have’ features and low-priority items.
Stage 2. Developer estimation
During the next step, developers assess how long it will take to program each function of the app and present the assessment in the form of a range (minimum to maximum) of hours of development.
Stage 3. Project manager estimation
It is common for developers to slightly overestimate the required amount of hours to develop, and, at this stage, the main priority of the project manager is to find the balance between price and quality. The PM reviews the development team estimates and includes the hours required for design, internal and external communications (team meetings, client demonstrations), focus group tests, code testing and bug fixing. Also, such processes as code merge between developers, refactoring and release are taken into account at this stage.
Stage 4. Final estimation
The project manager confirms his estimation with other members of the team, makes necessary corrections and presents the results to you.
Sometimes the mobile app development cost estimate template might look like an exact cost and time breakdown:
Still, other teams present their mobile app development cost estimate in a less detailed and more flexible manner. This eliminates protracted client approval of any minor changes to the list of works and let’s the team focus on the high-quality end result rather than just completing a list of tasks. After many years of development and multiple finished projects, we at Surf give a preference to this approach.
Chief Commercial Officer at Surf
When estimating app development, two pricing models are commonly used, that are fixed-price and time & material models.
With a fixed price model, a precise list of features, their realization and costs are determined during the estimation. If any additional works occur during development, they come at an extra cost and require a full agreement process with the client, which leads to a development team downtime, and further increase in the cost and time of development. If any planned works turn out to be unnecessary, the final price does not change for the client. This way, the fixed price model lacks flexibility, bears large financial and time risks, and can be suitable only for small and short-term projects.
Time & material
Time & material is a flexible model, which is focused not on building the exact list of features, but rather on the end result. The development process is done with monthly reporting and developers are allowed to build additional features without a full agreement process.
- The development team provides a rough top-level estimation divided into stages (sprints). The client agrees on the scale of works.
- The team starts building the app, presenting the work done to the client at the end of every sprint. The client pays only for what was done during the sprint.
- If necessary, the team suggests additional works and, upon the client’s agreement, includes them in the next sprint.
- In the end, the client receives the finished product, adapted to the current technical requirements and market demands (which may have changed since the estimation).
Because the majority of apps are complex projects, some small details (an additional button on a screen, a logic for an uncommon user flow) are inevitably neglected during the planning, and the time & material model enables developers to quickly and easily include them in the process. Also, if in the fixed price model the estimation of every feature includes potential complications, which may not come true after all, the time & material model reduces such risks for the development team, so it can offer more comfortable rates to the client.
Mobile app estimation is a process that takes into account all aspects of the future project and is based on a detailed technical specification. The process is conducted in several stages, from the project’s breakdown by screens or by features, to the estimation by developers and then by a project manager. Although the development team may provide to the client a precise cost estimate for app development and work on the fixed price model, a more rough and top-level estimation together with the time & material price model bears fewer risks for both parties and is more flexible to implement necessary changes when the development has already started.