How to Estimate the Cost of Your Mobile App

This post was first published on our blog.

What do the Montreal Olympic Stadium, the Sydney Opera House, and the Scottish Parliament Building all have in common?

They were all monumental budget-busters. The Montreal Olympic Stadium, completed in time for the 1976 Summer Olympics, was nicknamed “The Big O” due to its doughnut shape, and “The Big Owe”–because it smashed its budget by 1990%.

Here in Barcelona we have our own budget-guzzler in the shape of Antoni Gaudí’s Sagrada Familia. Work on the behemoth basilica started in 1882, and isn’t expected to be completed until 2026–one hundred years after Gaudí’s death. It’s annual budget is said to be around 25 million euros.

Thankfully, we’re in the business of building apps, not stadiums or basilicas. But the need for a quality budget estimate in both cases is the same.

How much does developing a mobile app actually cost? In this article, we’ll walk you through the mobile app development process–and show you how to estimate the cash you’ll need.

Hold on though–why listen to us? Click here to find out more about Mobile Jazz and our offer.

Nasty Surprises

Joan Martin has plenty of experience developing apps. He’s been at Mobile Jazz for four years, and currently heads up our mobile team. When he’s not enjoying some down time in the mountains, he’s managing the Mobile Team projects and dipping in and out of iOS engineering.

Joan our Mobile Team lead in Martinique.

If you’re looking to create an app in the near future, it may be tempting just to launch straight into it. Clock’s ticking, right? Joan advises against that:

“You need to be really clear on how much developing your mobile app will cost. It will help you adjust your expectations and prepare accordingly–avoiding nasty surprises later down the line.”

So it’s just a question of running the numbers? We like the enthusiasm. But first, you’re going to need to channel your inner politician and define your product manifesto.

The Product Manifesto

Imagine you’re at a networking event (a dream for some, a nightmare for others– but bear with us here). Someone asks you: “So what does your app do exactly?” Could you give them a clear answer? What if your grandparents asked the same question?

This is where it all begins–your product manifesto. And your entire team needs to be able to explain it to their grandparents. It will help you to define the development path and orientate all decisions around the key features.

It needs to be a simple and precise statement. It should convey–to anyone asking–what your product is, who it’s for, and the problem it solves.

Trivia time. Here are some famous product manifestos, but do you know the name of the product?

• “A platform where people can rent apartments from other people when traveling.”
• “Connect the world’s professionals to make them more productive and successful.”
• “All the music you’ll ever need. Millions of songs available instantly.”

How did you do? Those were manifestos for Airbnb, LinkedIn, and Spotify respectively.

Note the beauty of simplicity with all three of them. Focus is retained on the single major problem that the product solves, without getting lost in unimportant details.

Once you have a product manifesto, your team should revolve around it like a tennis ball around a swingball set. You’ll come back to it time and time again; from running the first product workshop, right through to the full launch. Don’t take this step lightly– the world’s most successful companies didn’t.

Assemble Your Team

Speaking of teams–do you have one?

MJ team members trekking in the Italian Alps.

Here are the key players:

• The Product people. This team should be highly involved in pinning down the manifesto. They constantly answer the question “what does our app do?” and make focused decisions around the key features.
• The Design people. Don’t skimp on excellent mobile designers–those that value user experience above everything else are the difference between an average app and a great one.
• The Development people. Find skilled engineers with experience. This team is laying down the foundation of your app–don’t build that foundation on quicksand.
• The Testing people

Hold on–the Testing people? Can’t we use our devs for that?

Would you ask the head chef to review her own restaurant? Even the best developers in the world have a biased understanding of the app. They’ve spent months implementing features by opening the app and testing their code in a certain way. As a result, they have blind spots. Here’s Joan again:

“A regular tester will approach the app as your users would, revealing corner cases and bugs that would have otherwise gone undiscovered. They’ll explore flows that both product owners and developers wouldn’t have planned for.”

So if the product owner and developers can’t test your app, who can? Well, just about anyone–friends, relatives, or a specialized testing company. You’ll get the best insights when someone beyond the bubble of your team explores the app for the first time.

Planning

While the Sagrada Familia may look like a free-for-all design frenzy, each facade has been carefully planned out–with engineers and constructors following the blueprint to every last millimeter.

We can’t imagine the planning involved in the Sagrada Familia.

Channel your inner Gaudí and meticulously plan the following:

• The product definition. This is your vision for your product. It should include the product concept, design requirements, features, target market, pricing points, and positioning strategy.
• A list of use cases. How might different segments of your audience use your app in different ways? These are sometimes referred to as user stories. When approaching this task, aim for the most basic specification of the app–just describe what the user can do with it. Brainstorm alternative uses to gather more use cases.
• Wireframes. UX designers convert previously defined specs into visual representations of user flows. Wireframes are the step between the specification document and the final designs. They “reveal” the app to your team–like the very first first ultrasound to show how a baby’s developing.
• Desired platforms. Do you want to run on Android? iOS? Both? Make sure you can justify running on your platforms from a business standpoint.
• Backend documentation. Guidance around the data access layer of your app and infrastructure.

And make sure you answer these additional questions:

• Will your app have social integrations? Which ones?
• Will your app come with push notifications? Under what circumstances?
• Which languages will your app support? Why?
• Which OS versions will your app support? Why?
• Will you optimize for tablet or smartphone? Why? Which one will you start with?
• Will your app be supported offline? Why / why not?

Think carefully about the answer to that last question. There’s no magic switch for “offline support”–building this functionality is a complex task. Your app needs to be able to fetch data from the internet, store it locally on the user’s device, and reuse it later when there’s no internet. There’s plenty of planning involved–planning that will take up more of your precious time.

Planning out your app’s screens with wireframes is an important step.

Estimating

Time is money, we all know that. So before we get down to dollars and cents, we need to count the hours and days.

First, we need to define how. Our main measurement unit will be days of work, with 1 day equal to 8 hours. At Mobile Jazz, we use a minimum value of 0.25 days–the equivalent of 2 hours. That’s because, based on our experience, anything smaller than that is unrealistic.

We’ll estimate by wireframe, because it’s the most authentic representation of a screen’s appearance within your app. It also reflects the complexity of user interactions and data management. Each wireframe must contain an estimation for these two things:

• UI Layout: Tasks related to the creation of user interface (UI) elements and their layout. This isn’t related to actions associated with UI interaction, but the complexity of implementing the different UI elements.
• Business logic: Tasks related to the application flow management and intelligence. For example, a button that–when pressed–-sends a request to the server, which then processes the received data, stores it in a database, compares it with other data, and finally outputs a result to the user. It also relates to the complexity of implementing screen navigation.

Discounting hangover days that follow raucous company parties, in general nothing takes less than 0.5 days for UI layout, and 0.5 days for business logic–1 day per screen.

Throw the following components into the equation:

• An additional 2 days for project setup
• An additional 15% for testing
• An additional 20% for bug fixing
• And an additional day for the release
• An additional 20% for project management

Still with us? Good. Now, developing for Android takes, on average, up to 1.5x more time than the iOS estimation. We asked Joan to explain:

“This figure comes from our experience. The Android API for creating the UI is more complex than the iOS API. It also has way more devices, each one with its own setup to control. In iOS, Apple automates this process–it’s much simpler.”

Example Estimation

Let’s imagine your team have got a killer new app for aggregating fake news from around the web. Here’s an example of what your app might consist of:

1. Login and registration.
2. Feed and (fake) news posts.
3. Your profile.
4. One push notification for new posts that appear in the feed.
5. Offline support.

Now here’s what your estimation might look like:

Bear in mind what hasn’t been included in this estimation:

• Backend development, evaluation, and testing.
• Cutting of designs and assets.
• The testing phase.
• New features.
• Maintenance and upgrades.

Cash Splash

It’s time. Armed with a smug grin, planning docs, an estimate, and a briefcase full of unmarked bills, you stride into the closest coworking space to hunt freelance engineers.

But what’s the right question to ask to find the best person for the job and fulfill your business needs? How about rate per hour?

That’s the wrong question to ask. Your estimation is already done–you know how much the whole process should take. So you could either hire someone who’s going to take longer and ruin the estimation, or someone who will work faster and hit the specified time frames.

The best question is: “What’s your experience?”

A skilled engineer will complete the project faster at a higher rate per hour. An amateur engineer will complete the project slower at a lower rate per hour.

We’ve done the math:

Some people will be tempted to slice some cash off that figure. So they go for a bad engineer, who claims they’ll do it faster at a lower rate. €60 per hour x 25 days = €12,000. Nice savings–but you get what you pay for. Here’s some of the things we’ve seen having worked with cheap agencies and junior developers:

• Poor (or non-existent) offline support
• Bad adaptation to different screen sizes
• Terrible support for old and new OS versions
• Weak software architecture–making your app unscalable
• A crap professional relationship

5 Steps to App Success

Getting the idea for an app is exciting. Launching it and watching it become a success is even more so. If you want to get there, give it the best chance possible by laying sound foundations first:

1. Define your app manifesto: What does it do?
2. Get a mobile UX/UI expert.
3. Find an experienced engineering team you feel good about.
4. Develop your app, implementing only the key features (everything else can wait).
5. If it’s too expensive, simplify your app by removing features and shaving hours off the estimate.

Follow these steps, and you and your team could build a masterpiece that doesn’t bust the budget.

How can Mobile Jazz help build your Sagrada Familia? Get in touch.