When business owners find themselves in the market for a new mobile app, they might be surprised at the upfront cost of development. After all, they might think: “It’s just an app, how much could it really cost to make?”

As developers, we can only come up with estimates for a custom mobile app, and at the end of the day the final price tag will come down to things like complexity (in both design and function), platform choice, and any ongoing maintenance or QA needs.

Here at Exquisite we typically break down an estimate into 3 core areas:

1. Design Features — Branding, animations, UX, etc.
2. Technical Features — API and platform integrations, app capabilities, etc.
3. Maintenance — server costs, bug fixes, OS upgrades, etc.

Entire books can be (and have been) written about each of these subjects, so it may seem daunting to try and get a grasp of all these elements at once. Nevertheless, in the following sections we’ll attempt to break down how each of these areas affects an estimate here at Exquisite, and hopefully demystify the process of budgeting for an app’s development.

UI is about the Experience

When we talk about the design of an app, we don’t just mean the color scheme or the icons used for buttons, and we’re not just talking about what transition animation are used. Indeed when Exquisite hashes out the overall design of an app we tend to consider both the aesthetics of the finished product, as well as the user experience.

In an example, a client might need only a lightly-customized bootstrap theme for a single-page app. A few form fields here, a log-in overlay there, and some API calls to grab any needed backend data, and you’re off to the races.

Bootstrap Themes are Simple and Inexpensive to Implement

In the more complex cases, clients may require a fully customized, built-from-scratch, multi-screen application with dozens of ways to navigate between each stage of the experience, with each stage being tightly coupled to the back-end logic. If, for example, if we were building a process for entering health data, we might need to change the types of data available for a user to track depending on their conditions. A diabetic person might need to enter their blood-sugar readings, but a non-diabetic person probably won’t, and the style of the data entry screens should nonetheless remain consistent from user to user.

Each step of the design of such an app would need to be intuitive and slick enough to keep the user engaged through the whole process, and ultimately might involve a lot of back-and-forth and some tough choices on the part of the client about what can and cannot be dialed back.

Wireframes, Interfaces, and Testing

In either case, our design process starts with a schematic of how a user is meant to use the app–a so-called “user journey”. This helps us understand how many different screens an app will have, and thus how much overall work we’ll need to put into the design. This is the shortest part of the design process, and is where we get a real sense of the scope of the design work. This phase typically takes around 3–5 hours.

Next up, we create wireframes based on the user journey–essentially mock-ups of the finished project that act as a scaffold for the more “artistic” design work. The wireframes have no frills and might use programmer art where real design assets might go. It is at this point that we flesh out how the app will look with the client by sketching out where the buttons, fields, text, and navigation will sit. This back-and-forth usually means that the wireframing stage takes around half that of the design: between 40 and 50 hours, give or take.

After this scaffolding work is done, we can start working on the actual design of the elements we laid down in the wireframe. At that point we begin considering things like the color choices, animations, fonts, and the overall “style” of the app. We try to always be mindful of the brand image the client is ultimately going for, and so this stage does require quite a bit of input from the client.

Together, the wireframing and design of an app take the bulk of the front-end time, at around 40–50 hours for each part. After the design is done, a prospective client could be looking at between 80 to 120 hours of front-end work from start to finish. It’s also important to note that this estimate only accounts for a first-pass attempt.

After completing a design, it goes through a user-testing process. For us this means either observing as people use the app, or the use of a service like usabilityhub. During testing we try to figure out whether users are moving through the user journey in the way we intended, or whether they are failing to move past a certain stage. For example, we might find at this point that e-commerce customers are spending lots of time on the site, but are seldom adding itemsto their carts, or are failing to use a “wishlist” feature we intended to make prominent.

More often than not, this user testing leads to further design revisions, which lead to more testing. This part of the process is typically open-ended in terms of time commitment, and we try to rinse and repeat until we get it right.

For some, this process can seem like overkill, but our experience tells us that (over the long run) it’s the user experience that users notice the most.

In other words, we can build all the fancy state-of-the-art backend systems in the world, but users aren’t going to stick around if they’re turned off by the app’s very design. And since iterating on design is 80–90% cheaper than iterating on code, putting in the extra time to make sure it’s perfect is the best way to maximize ROI.

Technical Features: Complexity Can Cost You

It stands to reason that the more complicated the features of an app are, the more expensive it will be to develop.

A complex app more often than not needs things like third-party integrations, server-side logic, admin panels, or the use of mobile hardware like Bluetooth or GPS, and each of these has its own cost in terms of both developer time and potentially subscription costs in the case of third-party services.

There are tons of technologies that go into the more involved feature sets: databases, machine learning libraries, front-end frameworks, the list goes on. Each layer of new technology adds complexity, time, and requisite knowledge to a project, and thus more cost.

And it’s not just complexity that has an overall effect on on the project. A developer must contend with other considerations such as whether or not an app is being built from scratch, whether it’s a native or cross-platform app, or whether the core logic can use existing open source libraries versus 100% custom code.

Each of these decisions has their own benefits and caveats, but taken together they can mean the difference between a $25,000 app and a $100,000 one.

Native vs. Cross-Platform

Building an app natively -using Swift or Java for iOS or Android respectively–will typically incur a larger time commitment. This is especially true if, for example, the app needs to be accessible on multiple app stores individually (iOS and Google Play) instead of a single marketplace. In such a case, the app essentially needs multiple codebases: one for iOS and another for Android, and yet another for any other requested platforms (blackberry anybody?).

That may make native sound like a non-starter, but native codebases have the potential to be more powerful and provides access to more built-in hardware features for the mobile devices the app runs on. Depending on the requirements, a native app might be exactly what the doctor ordered.

If your app has less of a need for things like GPS, NFC, or Bluetooth, then another–potentially cheaper–path is open to you: A cross-platform codebase.

Now, whether to build a cross-platform app or a native one is a topic far outside the scope of this article, but one which we’ve written about elsewhere. Suffice it to say, though, that in exchange for slightly restricted access to advanced hardware features, writing a react native app or a progressive web-app tends to take between 25% and 50% less time than an separate app on the two major platforms. Cross-platform codebases have their limitations, but this difference in effort means that the decision to forego a separate native codebase for individual platforms can mean a shippable product in 4–6 months instead of 12.

And speaking of time-to-ship, our estimates also tend to take into account how much code has already been written.

Built from Scratch vs. Existing Projects

Whether a project is being built from scratch from existing codebase similarly has an effect on the cost.

There are many reasons that existing projects might be easier or harder to work on than a blank slate, but in the end it all comes down to the fact that existing projects naturally bear the marks of their original creators.

Frankly, sometimes it turns out that the code is simply poorly written. Now, coding is an art form, and sometimes what looks like poor code is simply not what our devs are used to. We can’t tell you, however, how many times we’ve had a client tell us that their previous developer did 80% of the work, only to find out that in reality about 30% of the code was complete.

What’s more, because being contracted to work on an existing project inevitably requires a billable discovery phase upfront, it’s also imperative that we be able to communicate amicably with the outgoing developers. Without documentation or knowledge of existing bugs or quirks in the code, the discovery phase becomes more difficult, and inevitably becomes a substantial chunk of the project’s billable hours. For an optimal project handoff, we need a collaborative knowledge transfer, and not everyone is willing to provide that.

Backend Code

Whether an app is for scheduling babysitting hours, finding specialized recipes, tracking disease symptoms, or simply displaying your blog to the world, it’ll probably need a database for storing product information, a payment processor for handling payments, or a CMS for handling blog content. In other words: unless your app is as simple as can be–think calculators or basic to-do apps–it’s very likely to need some sort of backend system.

The most popular backend architectures often have many off-the-shelf solutions that can make writing parts of an app (and sometimes most of an app) much simpler. One extremely common example comes from the Shopify software development kit (SDK) which enables store owners to create iOS and Android apps that use Shopify’s functionality to do all the things you would expect an e-commerce store to be able to do (carts, products, discount codes, payment etc.).

Off the shelf components need not come in the form of SaaS platforms like Shopify, either. It turns out that in this the year 2019, more often than not another developer has already written tools to solve 75% of the problems you need to solve, and all a developer needs to do is use them. Open source software like FuturePress, a javascript library that can let a website render Epub files on nearly any modern browser, is for example a huge boon for the cost-conscious app developer.

Of course having all these features handled by off-the-shelf components can drastically reduce the development time for the “guts” of an app, but as with all good things such simplicity comes with potential caveats.

First and foremost among these is that simplicity can sometimes end up hamstringing an app’s scalability. WordPress, for example, is a fantastic solution for slowly changing sites with mostly static content likes blogs. It is on the other hand not particularly well-suited to dynamic content like an extensive product catalogue with need of many searches and filters, and potentially very high amounts of traffic.

On top of scaling issues, the potential need (present or future) for the significant customization of off-the-shelf components can actually have an even higher overhead for a developer than simply writing it from scratch. Like we discussed in the previous section, making changes to another dev’s codebase is never a trivial task.

All in all, development time (and thus cost) depends largely on what features an app has, their individual complexity, and the availability and feasibility of using pre-existing open-source software and SaaS platforms. For a good rule of thumb here, simply consider how common the feature-set you’re asking for is–if you’re building a pretty vanilla e-commerce store then chances are we’ve done it before, there are pre-existing solutions that are feasible to use, and it’ll be fairly affordable to build. That said, if you’re building something completely new that nobody has done before with complicated features nobody has ever seen… that’s clearly going to cost a pretty penny.

Another thing that turns users off is an app that is riddled with bugs, or an outdated app that becomes obsolete with a new operating system update. Which brings us to the final, often overlooked step in the app development process: QA and Maintenance.

QA, Maintenance, and Upkeep

It’s tempting to stop there and declare the app complete, but to stop at this point would be to ignore the three things that keep apps healthy over the long run: Testing, Maintenance, and Upkeep.

Testing, both during and after the app is built, ensures that the app performs as expected and (perhaps more importantly) that any changes made over time don’t break anything. Those changes often come from the maintenance process, in which we fix bugs, add quality of life features for users, or update any third party software components.

And of course, there’s the question of cost and scaling.

We consider all of these things when drawing up an estimate, because we care about the long term health of our clients’ apps, and we feel that should be reflected in our pricing.

Quality Assurance

QA, known to many developers nowadays as “testing”, exists at Exquisitef in two main parts: Unit Testing and System Testing. Unit testing deals with each new component added to an app individually, and System Testing deals with how the app functions as a whole from a performance and usability perspective.

For us, unit testing is typically done as we build the app, with our developers looking over each others code and testing it every step of the way. System testing, on the other hand, is typically done once the whole app is complete. System testing is especially important because we can involve the client in the process, and we’ll often realign the app’s development as a result.

Overall QA does exactly as its namesake would suggest: it assures both us and the client that what we’re writing is correct. Once our tests are run and we’re comfortable with the end result, it’s finally time to let the app out into the world.

From here it’s (mostly) smooth sailing, but in our modern times no app can afford to rest on its laurels. Software updates, operating system upgrades, and hardware improvements mean that apps need to continue to adapt to a changing technological landscape.

And so now we need to talk about what happens after the app is built. But you might be pleased to know that this is the shortest section, and if you’re still with us at this point we probably won’t have to sell you too much on the importance of maintenance for maintaining a long-term ROI.

Maintenance and Upkeep

Like any well-oiled machine, a well-functioning app needs to be maintained over time.

Most apps nowadays run their back-ends on cloud service providers like AWS, Google Cloud, or Microsoft’s Azure, which (depending on the scale required) can cost pennies, or thousands of dollars each month. In addition, many third party services (such as payment systems) that an app might use operate under a SaaS model, requiring subscription costs to use. As an app gains popularity its needs in both these areas are likely to grow, and so too do the costs of its upkeep.

What’s more, once an app has been battle tested in the real world with real users, bugs are bound to crop up that will need addressing on a continual basis.

With all of these things in mind, we typically estimate the cost for ongoing maintenance to be around 25% of the original development cost for each year after completion.

So What’s The Damage, Really?

Like we said at the beginning, this can all be pretty daunting and it can be hard to juggle all of these costs in your mind all at once. So the question most people ask after hearing all of this is typically: “So what’s this really going to cost me, then?”

The answer, as we’ve seen, is complicated, but in our experience most apps run our clients between $25k and $100k, plus a ~25% continued maintenance cost for future bug fixes and server costs.

That might seem like quite a hefty investment for “just an app”, but in this day and age a stellar app experience is practically a necessity for a business to succeed.

Ultimately, what you spend is based on what you need, and how effectively you communicate that need. With the knowledge we’ve shared here, we hope that you now feel comfortable approaching freelancers, agencies, or even your own developers armed with the knowledge of what should go into building a stellar app experience.