How much does a mobile app cost?
There are 7 factors that affect the cost of developing a mobile and web app. Learn some practical tips on how to reduce the expenses. What affects the value of investment in an application? In the article I point out the most important elements that should be taken into account when planning an application.
Meeting needs vs. the cost of developing a mobile app
Start your application project with a plan, and preferably a definition of your business needs. At this stage, you most likely know what your organization is missing. For example:
- customer service is too much of a cost,
- orders are handled too slowly,
- you want to give customers a new quality of service,
- customers don't have one place to find promotions and current offers,
- services are difficult to access for the customer,
- you are ineffectively reaching customers with your communications.
For most companies, these will be issues that ultimately affect the bottom line. With a properly developed app, the improvement in your bottom line will be much higher than the cost of creating a mobile or web app. What should you do to make sure that the application efficiently implements your plan?
Defining the objectives of the application
The next step in determining your needs is to pinpoint the objectives that will address your business needs. In order for the cost of a mobile app, or a web app, to pay for itself within the expected time, you need to identify business goals that will have some specific characteristics.
The objective should be:
- measurable, i.e., indicated by a number, such as a 20% reduction in costs in the customer service department, or an increase in the speed of order fulfillment by 30% within a specified time,
- achievable - it is easier to work with a project whose effect is within reach, i.e. we are not talking about a 3000% increase in revenue value within 6 months,
- specific - referring to a clearly defined area of business, e.g. time of making SaaS service available to a business client, or the time of servicing a lead from inquiry to sending an offer.
Once you've identified the needs and associated business goals - it is easy to define the so-called definition of done.
This is information about whether a particular goal has been achieved. Definition of done refers to a specific selected functionality of the system (e.g. launch of the chatbot function, which will relieve the customer service) and also to the achievement of the previously indicated goal. Having prepared these elements, you are able to start working with the IT supplier on the documentation of the project. The more precisely the goals to be achieved are described, the easier it will be to find technological solutions that will lead to their achievement.
How does technology choice affect the cost of a mobile app?
The choice of technology significantly affects the cost of a mobile and web application. It is especially important in the case of mobile technologies. It will be cheaper to use hybrid technology than to implement the project based on native languages (Swift for iOS and Kotlin for Android).
If knowledge of programming languages and their capabilities is not your strong point, listen to the recommendation of the software house with which you will work on the project. Such a recommendation is always worth consulting. However, remember to communicate the full knowledge, i.e. business goals and needs.
Why is it so important? Here are sample reasons:
- native solutions are characterized by a higher level of security (than, for example, PWA). For example, we run a banking service so we care about the security of our users for a particular reason, thus the recommendation of native technology is most appropriate;
- if you want to create an application that will have functionalities based on e.g. the position of the phone (e.g. rotation) then the effect of the highest usage of the phone's functions will take place with native solutions;
- if you want to test an idea and not invest too much at the beginning - here PWA can be a good solution.
The choice of technology may be determined by factors such as:
- a set of business goals and needs from the first part of the article,
- project funds,
- safety requirements,
- business model,
- use of phone features.
So remember to accept arguments like "mister, why spend when you can do PWA here which is 3 times cheaper?" or "do you want to drive a toddler or a Mercedes?".
Communication and management system in the context of application cost
You already have a great plan and selected technology, which optimally covers your needs and goals within the assumed budget. It would seem that from this point on it is easy, because the rest is just technical stuff. It is enough to check if all the buttons work and the application itself looks nice.
Communication and the adopted project management system (or lack thereof) can definitely contribute to the realization of overtime in situations like these:
- The designated Product Owner on your side is completely dependent on the CEO and his moods, who sometimes likes the graphic design and sometimes doesn't. That is why we return several times during the project to the already completed (and theoretically closed) sprints to make changes (which in turn may imply further changes, e.g. interface layout changes).
- During the application development it turned out that there is a new system in the company, with which the developed application must communicate in order to exchange some data. The Product Owner finds out about it too late. The team working on the application has less time to analyze the documentation of the new system and implement the necessary changes.
- There is no designated Product Owner, in whose place you are dealing with a collective project team without a clear leader. In such a situation, developers may even receive mutually exclusive messages in extreme cases. There may be more frequent revisiting of already closed stages, introduction of changes, which in turn may affect subsequent phases.
The situations listed above mean that the cost of creating a mobile application can increase significantly. In each of these cases, we will be dealing with increased man-hours (or man-days) of work for developers and the entire team.
Later in the article, I will talk about an important aspect – the system of accounting with the contractor:
- Time & Material (billing based on hours accrued);
- Fixed price (settlement based on a predetermined amount).
At this point it is worth remembering that regardless of the chosen model, in case of changes described as examples – the contractor will charge additional working hours. The basis in such a situation will be the specification changed during the project. The moment when we change the specification is also of great importance. If it is relatively early in the project, it will probably be less costly than at the very end.
Does the number of views have a significant impact on the cost of the application?
Once you've written down the list of functionalities of an application or web service (functional requirements), it's worth doing an exercise.
Try to draw the application screens on a piece of paper. In pencil. For example: you are an internet provider. You want to launch a mobile application for subscribers. In the app, the user can:
- log in to your subscriber account,
- view your profile data and account history,
- ask a question (form),
- review currently available offers to modify your plan,
Five points, from which about 15-20 screens will be created. For example – a diagram of the user registration screen. The creation of each screen is the team’s time, and this has a direct impact on the cost of creating the application.
The impact of application integration on its cost
In the point with the number of views and in the earlier point with potential communication challenges, I mentioned potential integrations, for example with a payment system, ERP system, CRM or others.
Why can integrations have a significant impact on the cost of creating a mobile or web app?
Each potential system has several elements to look at:
- whether the system is an external system or created for internal purposes without a specific integration standard (e.g. in the case of the Przelewy24 payment system),
- whether there is properly prepared documentation for the system (or whether there is a person who knows the system from the technical side and is able to cooperate with the supplier on integration),
- the scope of integration, i.e. whether the application is to retrieve a single value from the indicated system or perform more complex operations with continuously refreshed data.
In other words:
- the smaller the scope of integration,
- the better the documentation of the project,
- the better defined the scope requirements are,
the fewer programming hours the component will require.
Project delivery model vs. application cost
The cost of creating an app also depends on the model we adopt for implementing our idea. The whole process can go in two directions (there are many shades of grey in between, but let's focus on the extreme cases):
- Our company, such as a chain of gas stations, wants to provide customers with an app through which the customer can pay for fuel at the pump.
- Our company is a startup that wants to test a brilliant idea.
- We are testing whether it will indeed be as positively received by the market as we expect.
In the first situation the application should be realized from the beginning to the end, i.e. its most important function - payment at the distributor - should be realized. The project of the application should have good documentation, defining business requirements, and the user themself should be able to pay freely using the application (integration with the payment system, with the POS system). In this case the investment in the application will be higher than in the second case.
In the second case, it is enough that we prepare a basic functionality based on the MVP model - a product in the minimum version, meeting the absolutely basic requirements. On this basis, the organization should collect knowledge among users whether our idea has a future and it is worth investing in the development of the application, or vice versa, and we should not risk (possibly change our original assumptions). Developing MVP, we do not invest large funds, but verify our idea based on a tool that is not necessarily perfected 100%.
T&M or Fixed price: choose the right billing method
The cooperation between the IT provider and the client is usually based on two billing models:
- Fixed Price – establishing a predetermined scope of work in exchange for a clearly defined amount. The key here is to make the project specification as detailed as possible, because there is not much room for potential changes. Less flexibility and at the same time greater risk means that suppliers usually add a certain percentage to the initial estimate (usually from 20 to 40%), which is supposed to mitigate the above risk. The cost of a mobile and web app may simply increase.
- Time & Material – here we rely on the established rate per work-hour, on the basis of which the project will be settled. At the end of the established settlement period (e.g. month) the contractor generates from the project system (e.g. Jira) a report of programmers' work divided into hours and tasks. This approach allows for a more flexible approach to the project specification (it does not have to be specified in advance with details), and the contractor themself pays for the real hours worked by the team.
A certain compromise is the mix approach, where we base a certain set of project functionalities on a fixed price and its subsequent stages are settled in T&M.
How to choose our model in order not to overpay on one hand and to get the project you expect on the other? Of course, it depends:
- Whether you have a predetermined budget that we cannot exceed in any way.
- Whether we care about the flexibility of the development team.
- Do we expect accurate reporting of the programmers’ time, as in T&M reports?
Summary: The cost of a mobile app and a web app
There are many factors that affect the cost of creating an app. It does not relate to the strictly technical aspect, but depends largely on us, ordering the project. If at the very beginning we clearly define our needs and goals, we leave less room for potential risks in miscommunication or functional scope. In this situation, the choice of T&M billing may simply turn out to be cheaper to implement.
Similarly, if we clearly define the competencies in our team, i.e. we identify the Product Owner who bears full responsibility and makes independent decisions about the project, we mitigate the risk that may generate unnecessary costs on endless changes and amendments.
Yet another important cost-creating factor is the implementation time. We all know the saying, "What goes around comes around", and even in the implementation of IT projects, it is sometimes worth reaching for the folk wisdom and prevention, rather than paying later for costly treatment. Therefore, we do not always have to implement all the functionalities right now, right away, in the first phase. The MoSCoW model, which allows you to determine the priority of a given functionality (must, should, could, would) can be our own safety buffer that will protect you from unnecessary costs and higher risk in the project implementation.