Cost drivers

1. Features & Functionality

It might sound obvious, but the more feature and functionality you put into your app – the costlier it is to develop. But you should remember that you don’t need a lot of functionality to create a really helpful app. It is advisable to divide your list of desirable features into different app releases, and not necessarily try to add everything in the first version. This allows you to keep the users engaged and entertained with regular updates, as well as ensuring that you develop an app that people actually want to use based on the feedback you get.

Implementing features like GPS, location services, maps, social sharing, push notification etc. isn’t necessarily time consuming to implement, but it depends on how advanced you need the implementation to be.

2. Target platform

Does your app need to be on all platforms, or do you want to test the response in the market first? No matter if you use native technology or cross platform, the fact remains true that the more platforms you target at once the more development time and cost is incurred. It is advisable to first target one platform and then add a second later.

The two major platforms are Apples iOS and Googles Android platform. The third “platform” that is emerging is Huawei, an Android version where Google Mobile Services is replaced by Huawei Mobile Services

3. UI/UX

You will need designers to make sure that the functionality translates well into a mobile design language. The major platforms all come with sets of standard design elements (buttons, lists, navigation etc.) based on mental models.

As these elements are used in most of the apps on the platform, the user will quickly recognize a button or a date picker. The more custom UI you make, the harder it will be to ensure that users understand it and for the developers to implement it. This may clash with companies design guidelines, making the priority of design polish more important than creating an understandable app.

We suggest that you look into polishing and making custom UI later, as it often add to the cost and makes the app harder to understand. There are few things that are more annoying that spending a lot of time on creating an element that nobody understands.

4. Number of screens

How “big” is the app, as in how many screens are required? Is the flow and interaction between the screens complex or not? Is it a hierarchy or logic that needs to flow in “all” directions? Do you show the same data in different ways (both map and list)? The number of screens usually have a direct connection to the cost of the app. Thinking twice about how many screens that are actually required may significantly reduce cost and might at the same time enhance the user experience.

At Shortcut we have made really small apps, in the context of number of screens, such as Fastr and Lederne. We have also worked on quite extensive apps, such as Bulder Bank and DNB.

5. Authentication / User registration

A lot of apps makes the users log in, so they can communicate with servers and get their information, as well as synchronizing data between devices. This requires some sort of authentication system. Some companies already have authentication services that they use on their existing websites or other services.

There are many ways of authenticating a user. It could be by using username/password, SMS, e-mail or through social services (FB, Twitter, Google, Apple etc.). All these ways of authenticating can be implemented one by one, or by using a framework (i.e. Firebase). Using a framework is often times the quickest and cheapest way of authenticating users. Building your own authentication service from scratch can be costly, but might give you more control of the data.

Some apps, like mobile banks or fintech-solutions, need to make sure that they know exactly who’s logging in. BankID is a solution that gives you that data, but is costly to implement and does not provide a very good user experience.

Not all apps need authentication or user registration. You could consider making the first version without it, as you might provide value for the user even though the data isn’t personalized.

6. Offline mode / caching

Does the app need to work off-line? If yes, this adds additional time for implementation. Most apps run some sort of call to a backend service in order to get the latest data upon opening the app. If the user is offline – that data won’t appear. To ensure the best user experience, we often store the data on the device. This both ensures that the loading of the data seems quicker, as well as ensuring that the user won’t access their information without internet connection.

An app will be in memory for a while after use, making sure that the user comes back to the same place, even without caching. This data will be lost if you run out of power, if the app crashes or the system dumps the memory in the to ensure that the phone acts optimally.

There are various ways of persistently storing the data – some ways more costly than others (although better). Persistently storing of data is recommended as a user most likely will expect to be able to get their data at all times.

7. 3rd party integrations

You might need some third party services to improve the app. It could be for databases, login-systems, analytics, crash reporting, push services, feedback systems, continuous integration and continuous delivery etc. While some of these services are free, other might come at a cost, especially if there is a lot of usage. Some of them might also need some configuration in some backend/cloud in order to work optimal, so it’s recommended to monitor this over time.

8. Accessibility

As of January 2021, all apps must comply with Web Content Accessibility Guidelines (WCAG 2.1) to ensure that cognitively and visually impaired may use the app or service. In Norway there are 19 statutory requirements for universal design. Native app development has tools to make compliance simple, but you will always need to take some time to ensure that it works properly.

9. Payment processing

If your app requires payments there is a few things to think about. If you’re selling digital services, you’ll need to use the platforms in-app purchase systems, that the platform might take a cut out of.

If you’re selling physical products or services you can accept “normal” payment through credit cards or other payment systems. In this category, there is a lot of different options. These options also take a cut from the payment. How much they take usually correlates with how easy it is to implement. Stripe might be the easiest solution to implement and use, but is also the costliest one. You could also use services like Vipps or NETS.

You could consider starting out with Stripe ensure that the app you are building has potential, and then later look into cutting the payment processing expenses.

Modern apps should also support Apple Pay and Google Pay, as they often are the easiest way to pay on the platforms.

10. Push notifications

Push notifications play a powerful role in engaging users with your app. When used intelligently, push notifications improve app engagement by almost 90%, studies suggest.  Yet, they also pose an opportunity to turn users against your app, used in the wrong way. Push notifications give you an opportunity to interact with users when they’re not in your app. Pairing push notifications with deep links lets you go a step further as it takes the user into a specific screen within your app experience, further simplifying the journey and getting them closer to the action you want them to take.

By using industry standards such as Googles Firebase, intelligent push notification strategies may be embedded at a reasonable cost.

11. Backend / Cloud

Most apps we make get some data from a web service and displays them. For some apps, we connect to existing services, while on other, we need to build everything from scratch. Sometimes we also need to extend the existing services in order to make the apps work better and add functionality. All web services have some cost attached to them, based on the usage.

Calculating the cost of building and maintaining a backend service could be its own article as there are several things to consider, However, creating your own backend system doesn’t need to be very costly. There are lot’s of modern service providers that make it easy to create and maintain affordable services for your app.

12. App Care

Post launch we like to address as the “app-care” phase. Potential bugs or crashes must be handled immediately, as well as scaling with volume. In addition you should expect to receive user feedback (which we really want) and respond to this by making adjustments to the app or providing new functionality.

Each year Apple and Google are updating their operating system and it’s important to be pro-active in ensuring that your app is working optimal with these updates. At Shortcut we have developed our annual “care-cycle” where we make sure to comply with platform revisions.

13. Languages

Some apps might need to be support multiple languages. We usually start out by making the apps in Norwegian first, and then do the translations when we know exactly what the content will be.

14. App technology – Native vs. Web vs. Hybrid

The perhaps most important choice to make when making an app is wether you chose a hybrid, web or native code platform. They all come with pro’s and con’s and the debate is active on what to chose. At Shortcut, being a mobile app pioner since the inception of apps, we have tried it all. Consensus is strong towards native if customer experience, security and utilization of the smartphones sensors comes first. At Shortcut we are native first on everything we do, simply because that’s what a premium app requires. That being said, we have experience developing on other code platforms. Our experience, however, is that the cost in the long run might be higher than if you just start by developing a native app.

You can read more about this topic in the blogpost (Norwegian) Hvordan velge riktig app-teknologi.

Conclusion

So, back to the initial question, how much does an app cost? Well, as we have tried to highlight in this article, it depends. But based on the above, we may generalize and say:

MVP: 4-8 weeks – 500 000 NOK – 1,5 MNOK

Medium app: 2-5 months – 1,5 – 2,5 MNOK

Large app: 6 months + 2,5 MNOK