What's involved in making a mobile app and why it's not easy

As a web developer, I have friends who come to me with ideas which should be "straight forward", "easy to do" or will "make us rich". On their part, their ideas do have a market a lot of the time (albiet not as big as they'd like to think), but that market is usually already dominated by a good solution, and it's the conversation that immediately gets my back up.

I know for them, they don't have an idea of what's truly involved, but this article aims to address this, and to see if my frustrations are universal among the development community when the assumption is, it's easy to make an app and anyone can make money from it.

How much does it cost to build an app?

The very first question that gets on my nerves, and yet again, I reiterate my understanding that this is my field of expertise and not theirs. At the same time I wouldn't say to a builder "how much would it cost to build a simple house?". What is a 'simple house' anyway? There's no fixed definition. The answer to this question is simply, how long is a piece of string?

Let's break apart a common app, and try and estimate a cost, or highlight time costs as this is a currency we're all familiar with but try and guestimate real-world costs along the way. Throughout this post, we'll use a 7 day weather forecasting app as an example.

Where's the data coming from?

If we're building a weather app, we're going to need weather data. In most cases, companies have to work hard to gather and package that data, so there's usually a cost involved to use and license it. Your app needs to pull this data from somewhere, via an API (Application Programming Interface).

When your app opens, or searches for weather for a given area, it makes a call to the API for the data for a given location. I'd imagine that most weather APIs would charge on a block (say of 1,000 calls) or on a per call basis. There's ways to keep the cost down, usually by having a middle-man to do some clever stuff to reduce cost. We don't want to make a call to the weather API per user of our app.

We don't want each app to make a call to our Weather API if it costs per call

The middle-man – our own web service

The middle-man is our own web service which handles requests between the mobile app and the API. If we had 20 app users requesting weather information for London, we don't want to pay for the same 20 calls to the weather API, so we cache the response from the API so the app users receive the same data and there's a single call to the Weather API.

We might also want to change the shape of the data to suit our App's requirements too, or change the data provider. These are other reasons why we'd want our own web service between the mobile app users and our Weather data provider.

We'll need to build a web service to cache data, secure data and keep our data costs down.

This service needs building, hosting and making secure. All of this has a cost, time and in some cases, legal implications. Depending on how many users we have for our app, the costs of the infrastructure and quickly grow, meaning we have a substantial outgoing which affects the profitability of our app. Depending on what else we need our service to provide, we may need to seek legal advice if it's handling user registrations etc, and of course, the more it does, the greater the development cost.

So we've now got the following costs:

• Cost of our Weather API and the ongoing cost of this third party data provider
• The cost in time to build our web service that reduces the amount of calls to the third party weather data provider – maybe around 50 hours to design, scope, build and deliver a MVP (minimum viable product – no bells or whistles, just enough to get us started)
• The ongoing costs to host and scale our webservice – probably around £50 to £100 a month for a load-balanced setup with moderate traffic
• Legal fees if we require outside support to comply with international data laws (where required)
• Insurances for if our data holds any kind of personal information (ie; a user account for our mobile user)

All of these costs are before we've even built our mobile app!

Now we've got our web service and data, the app's simple to build, right?

Wrong. There's so many different approaches we can take to build our app, and different platforms we would like to support. Each platform has many devices with many different screensizes, so the user experience differs greatly with all of these variables.

Let's consider the two big platforms, iOS (as used by Apple on its iPad and iPhone devices) and Android (used by pretty much everyone else, in particular Samsung and Sony). Each platform has its own SDK which is a Software Development Kit. We could go down the web app route, where there's one communal codebase, but this can be restrictive, and often slow.

'Simplicity' comes at a cost, usual a design, research and development cost.

Let's say we go down the native route, each app has to be designed and built in its respective SDK, something as 'simple' is quite often, anything but simple. 'Simplicity' comes at a cost, usual a design, research and development cost. For something to be 'simple to use', means that the user experience (referred to as UX) is well thought out, often with research by a UX specialist. Quite often this isn't perfect first time, and various behavioural analytics are collected and analyised to get it right over several iterations.

Next comes the development. For things to work in a 'simple' manner, all aspects of how an app is used by its audience is considered. Things that seamingly 'simple' like search quite often are difficult too. The better the search function, the more that happens in the background to provide truly relevant results.

Once we've built our app, we need to submit it to our relevant app stores; the Apple App Store and Google Play. We're going to need to pay for that, last time I checked I think Apple's developer resource subscription was £60 a year. Once we've submitted our apps, there's a real risk that they may need further work, which is more time.

So during the app development we've got yet more costs:

• Cost in time (or money) for UX, design, prototyping etc – maybe 30 hours as a rough guess, but specialists cost money, around £30 a hour is the going rate in Manchester for a UX designer
• Development cost for each platform we target – around 40 hours per app for something polished, tested and production ready
• Developer programme subscriptions – around £60 last time I checked

We've got our app, our web service, we're good to go, right?

Wrong again. There are further considerations that need to be taken into account. Do we have a website for our app? Have we decided how we're going to support our customers? Do we need to pay tax on the income from our app? You guessed it, more time, more cost. I'm summarising here, but these are real things we need to consider.

I've got a side project which I run, Tides Today, that used to go under a different name. I had a 'cease and desist' notice from a group of solictors, informing me that I was using a registered name without permission. I promptly complied after seeking legal advice and changed the name. For me to protect the name, it's (you guessed it) yet more time and money.

Legal obligations

Aside from any civil legal obligations, there's criminal ones around data protection, in particular a new set of rules around GDPR which come into law in the UK on 26th May 2018. These laws require among other things, established policies for handling user data, whether it directly identifies an individual or not.

Conclusion – building an app is a ballache – you may never make money

The title says it all really. So next time you say to your developer friend "I have a great idea for an app, we'll make loads from it", you have an insight into what's truly involved.

There's loads I've summarised and completely missed out here, but you get the idea. Building an app requires a lot of time, money, patience, skill, and even after all these investments, chances are there's already an app out there that does a great job.

As usual, any thoughts or conversation, fire away in the comments.