How to Estimate a Mobile App Development Project
How much does it cost to develop an app? Giving an answer to this question is the first things a development team will do before starting work on your project. Estimation is what will clearly show you if a company is right for you and if you’re the right client for them.
Not only is estimation our first stage at Mobindustry when a new client comes to us with a project in mind – it’s also essential.
This article is based on our own experience and it is written for clients who want to hear about the estimation process from our company’s perspective. We believe that this will help you better understand our internal procedures even before we start working on your app.
You’ll find out how to estimate mobile projects, what you need to provide so we can make an estimate, and how how much time it takes us to calculate mobile application budget.
Types of Estimates
We make two types of estimates for our clients:
- Preliminary (rough) estimates
- Detailed estimates
A preliminary estimate is a very general estimate that doesn’t take too many details into account. It only requires a few hours on our part. Be aware that this estimate is very approximate, however, and that it will likely be only about 70% accurate. This means that you should be ready for the real cost to be higher or lower by about 30% of the preliminary estimate.
The goal of a preliminary estimate is to find out whether a client and a development company are right for each other.
After our client confirms that they’re comfortable with the cost of the preliminary estimate, we proceed with a detailed estimate.
We make a detailed estimate when we know all the details about your app. The detailed estimate takes more time and effort on our part because it involves the whole development team. Usually, a detailed estimate takes no fewer than two days.
Here’s how the process of coming up with a detailed estimate goes:
Step 1. Functional breakdown
We decompose the whole technical specification document into small pieces that are easier to estimate. There are two approaches to decomposition:
- By screens
- By functions
Decomposition by screens looks like wireframes where you can see all the functions on each screen. For example, the login screen might contain the following functions:
- — Login and password validation
- — Password recovery
- — Sign in
- — Login via social media (e.g. Facebook, Google)
The technical specification will contain information about the exact functions that need to be there.
Step 2. Developer estimates
The next step involves developers. Their task at this point is to estimate how many hours it will take to implement each function. Usually their estimates come as a range indicating minimum and maximum hours.
Note that developers tend to overestimate hours in case something takes more time than they think. For example, developers might estimate a project that typically takes 300 hours to develop as a 500-hour project.
This is where the project manager steps in.
Step 3. Project manager estimate
The project manager connects you to your development team. That’s why it’s their duty to find a compromise between quality and budget.
At the final estimation stage, the project manager looks over the developers’ estimates and accounts for other things such as:
- — Risks
- — Communication (daily team meetings, meetings with you, calls, demonstrations, work summaries)
- — Testing
- — Design
- — Bug fixes
- — Internal acceptance
There are also other processes that take time and should be included in the detailed estimate. For example, if there are two Android or two iOS developers on a team, they’ll need some time at the end of each day to merge their code.
Apart from that, build creation also takes a rather significant amount of time – up to 10% of total development time.
When creating a detailed estimate, a project manager has to take into account the release process – as well as refactoring if the project is large.
Step 4. Final estimate
All these modifications mentioned above are then confirmed by developers and presented to you. In the end, after we estimate budget for mobile app, you get a document with all the information including the names of your sales manager, project manager, and other members of the development team.
As you can see, detailed estimation is a hard process that involves all team members. Outsourcing companies know that only 5% of all client requests actually become projects. For this reason, we can’t provide detailed estimates for every project that comes to us. That’s why it’s considered best practice to make a rough estimate first to find out if a client is ready to work with a particular company.
There are two major pricing models that we use:
- Firm fixed price
- Time & Materials
Firm fixed price involves an extremely detailed set of requirements that can’t be changed.
The Time & Materials model is more flexible. With this model, you pay directly for the time spent on development. The amount of time spent can vary based on new functions you request and changes to requirements.
than what you expected.
In this case, there are three options: you either have to accept
Which model is best for you depends on the type of project you’re developing, but at Mobindustry we usually suggest the Time & Materials model because it allows us to make changes and adjust the app according to your wishes, which may change during development.
Types of Clients
In our experience, there are three types of clients who come to us with projects. The main difference for us as a development team is how detailed each client’s vision is.
When a client comes to us, they may share:
- Complete technical specifications
- A vision for an application
The process of working with a client depends on what they come to us with. Let’s discuss these differences in more detail.
Case 1: Complete Technical Specification
This is the best case scenario. If a client has complete technical specifications, it means they have a clear vision of what they want their mobile app to look like, and we know exactly how to estimate a mobile app budget.
A technical specification is a document with wireframes and algorithms that are clear and specific.
It’s great if the technical specification document also includes API documentation for integration with backend.
If you have a technical specification, that’s great! All we have to do is make a detailed estimate.
Case 2: Wireframes
In this case a client has wireframes or so-called mockups that show the overall principles of the app’s business logic. In other words, wireframes show screens, functions, and their relations.
This document, however, is different from a technical specification because it contains only general information and lacks details. It may be interpreted in various ways. Let me explain with a simple example.
Imagine a login screen. In wireframes, you’ll see screens that show up after the user performs some action, for example after they log in.
But what actually happens when a login and password are entered? Login credentials go to the server, which checks whether there’s a user with the given login and password and returns data to the mobile client – your app.
What happens during this confirmation process on the screen? Maybe there’s a loader? Or maybe there isn’t?
And what happens if the password is wrong? Unlike a technical specification, wireframes don’t contain such information and don’t take intermediate conditions into account.
What does this mean for us as developers and for you as a client? The simple answer is differing interpretations.
Intermediate conditions aren’t discussed in detail at the estimation stage, and you need to understand that the less initial data we have (wireframes as opposed to a technical specification, for example), the higher the probability that you’ll get something that’s different the applications as it is, pay for changes during building, or involve business analysis department that will create a detailed technical specification document. As you can see, an estimate based only on wireframes is riskier, and there may be unpredictable changes to the budget.
Agile development is a better choice in this case both for you and your development team.
Case 3: Application vision
This case is the riskiest, as the client doesn’t have anything but a vision of what they would like to create. An app vision contains only a concept and few details.
In this case, we offer to involve our business analysis department to determine details and create a technical specification document. This is a separate service that also costs some money.
When business analysts start working with you, they ask all possible questions about ambiguities in your app’s concept. Of course, most of the details about intermediate states of screens developers can find in guidelines for iOS and Android applications, but there can still be some questions. This is what business analysts are for.
At Mobindustry, we insist that our clients work with our business analysts because they help us manage expectations and deliver clear instructions to our developers. Why is managing expectations so important? Because it helps us avoid misunderstandings and control the development process – and makes sure you know exactly what you’ll get in the end.
We prefer not to work with clients who refuse to create a technical specification document. In 90% of cases, these clients are disappointed with the final application. We take our work seriously, and we expect the same attitude from our clients.
However, there is another option: an open budget.
An open budget model is possible only if a client who isn’t an expert in mobile development wants to learn how to express their wishes and demands to developers.
This is Agile development, and it works like this:
1. The whole project is divided into delivery phases, and you confirm their frequency.
2. We agree on on key functionality without which the app wouldn’t make any sense. Other functionality goes to the backlog.
3. After each delivery phase comes time for an iteration. This is when our development team gets feedback from you.
4. When the next iteration comes, we look at what’s in the backlog and decide what functions will be added in this iteration and which can be set aside until a future one.
This process continues, and in this way we understand what you want from the development process.
When making a rough estimate for development with an open budget, we provide an average risk multiplier. As we begin development, we suggest coming to a consensus concerning functionality we can implement within your budget.
Estimation is the first stage toward a quality application and collaboration between an outsourcing company and a client.
While the purpose of a rough estimate is to find out if a development team and a client are speaking the same language, a detailed estimate works as a guide for the whole development process.
It’s great if you already have a technical specification for your project, but if you don’t, Mobindustry is ready to help you create one by working with our business analysis department.
Note, that you budget will also consist of app advertising cost, after your application is ready. Think about the cost to promote your app beforehand, otherwise you won’t be able to present it to wide audience and attract users.