How much does it cost to build a mobile app? (— and how do you do it!).

Can you build me a mobile app? How much does it cost to build a mobile app? At Fastdev we get asked these questions — a lot. In this article, we explain how we go about building mobile applications and how we cost them.

Building your mobile application.
In the beginning, there is — the idea.
When a customer comes to us, they might want to either create a clone of Uber or something more specific, like an app to manage requests for a car repair shop.
Usually, the customer has a pretty clear image of the problem that the application needs to solve. However, the customer rarely has any real images of the screens and little idea of what exactly happens on each one.
Begin with the end in mind.
Therefore, the first thing we do is draw up the idea. By drawing all the screens we can agree on exactly what the app will do – before we start building it.
As we are drawing up the screens we are also defining the SCOPE. The scope is the list of use cases/functions that the application should cover.
Be like a child.
“…putting on our 5-year-old hats.”
Before we start building we must first make sure what we have drawn up is what the users need.
This is when we have to “put on our 5-year-old hats”. It’s not enough just to look at the screens. You have to imagine actually using the mobile app. It’s important to consider it in the right context. At Fastdev we built an app to book boats, the customer accepted it but nobody realized there are often security gates you need to go through to access the boats – so we needed to consider this and include this information for users.

The cost of building a mobile application.
How we cost building your app.
This is fairly simple, dependant on the complexity of the mobile application. First, we break down all the functions in your desired application. Next, we estimate the implementation effort in hours.
Having the list of functions and estimated cost, the customer can play with this estimation by changing the priorities of the use cases, keeping all or potentially excluding some of them.
As we have built many of these functions before, we can do them very efficiently.
The people behind a mobile application.
1. Design. UX and UI.
- UX (user experience) design is the high-level design that should represent the flow more than the visual part (touch here on this screen, this screen appears, and so on).
- UI design (user interface) includes graphics and all the visual parts (logos, colours, fonts, etc.). The application is rarely developed for a specific phone or tablet (although there are such cases when the application is distributed together with the device). This can make the design stage difficult. Usually, the design should work for a wide range of devices on which the application will run.
The Designer is initially the most important member of the application development team.
2. Client-side.
This is what you see on your device’s screen: buttons, fields, and images, normally displayed on the screen according to the design. Client-side is also in charge of removing unused data from the memory and avoiding memory leaks. Android applications and iOS applications are implemented in different languages — this is why it is not common for a person to be an Android developer AND an iOS developer. Some developers have experience with cross-platform application development. Cross-platform client-side applications are applications that should work normally both platforms.
However, cross-platform applications lack some very useful tools and libraries leading to the fact that the application can work on both platforms but the function performance can be cut [read more in our article Native vs Cross platform].
Android developer, and/or iOS developer, and/or X-platform developer. These guys are at the very front of the application’s development.
3. Backend.
If the application gathers, stores, and processes any data (logins, encrypted passwords, names, avatars, etc.), it should be stored in a database. There is no such thing as a universal database, they differ for every application. This is why a database needs to be designed and developed. Server-side. Applications that deal with data need to process it. This is not done within an application itself. All the applications (client-side) do is send the data to the server, and the server processes it, stores it, and sends the replies back to the application. API (Application Programming Interface) this, simply put, is the set of rules by which the server-side and the client-side exchange the information. As the database is unique for each application, the API is unique, too.
Usually, and for quite simple applications, all 3 points mentioned above (database, server-side, API) are developed by one and the same person —the backend developer.
4. QA engineer.
After the application (or its countable part) is implemented, we add a QA engineer (Quality Assessment). The QA tests the application in every possible way by entering any possible data in every possible way, by opening multiple instances of the application, by breaking the normal workflow of the application in every and any possible way. They push and stress the mobile application as much as they can.
Why are they separate people? The QA and the developer? Imagine, you baked a great cake, it smelt good, and looked fantastic, then suddenly, you notice that your finger misses a ring, you might have forgotten the ring inside the cake, and you need to get into the cake and check (of course, the cake will be ruined). Would you prefer doing it yourself? Or ask someone else who has no idea how many hours and how much effort you spent to bake the masterpiece, someone who will easily get inside the cake, find your missing ring (QAs call it a bug), and who might also notice that the cake is actually not baked enough on the inside (“major bug”). I think you would agree, that the second option probably works best. This is why QA engineers are separate specialists in breaking.
Depending on the application, 1, 2 or more QAs are needed. After QAs find bugs, they are fixed by the client-side and backend developers. This stage is called ‘bugfix’ and it is a very unpredictable part of the application development process.
5. Project Manager.
Finally, to ensure that the development process goes as smoothly as possible, we add a Project Manager to the team. The PM works to: 1) serve as a translator from the customer’s to the developer’s language and back, 2) controls the development process to stay within budgets and deadlines. The PM also works to motivate the team and resolve all internal conflicts.
The Project Manager is responsible for development process control.
So how much does it actually cost?
So, even when we are creating a simple app for both mobile OSs we would need up to 6 people: designer, backend developer, Android developer, iOS developer, QA, and a PM.
We usually spend one to three months on building it, and that boils down to somewhere around 50.000 – 500.000 SEK.
In some cases, a mobile app is not the right solution. A simple web application can be enough and sometimes even better, as the users don’t have to find and download the mobile app from Google/App store.
The small print — maintenance.
Don’t forget, you’ll most probably be charged ‘maintenance’. It’s rare that an application development ends with the first version (even a very simple one)…
- Coming soon — check out our client case study Trädgårdskonsult and how we solved their problem in 2 weeks with a simple web based application.