How much does it cost to develop an app?There are a great many blog posts and threads that provide a direct dollar value answer this question, including:
- Digital product agency SFCD, which uses the example of a notes app and estimates $37,000 for a small notes app or $140,800 for a more complex notes app.
- Mobile app design and development company Fueled, which says $100,000-$150,000 for a minimal viable product.
- A Stackoverflow thread which features answers from the developers of two popular apps: Twitterrific, coming in at $250,000 and Obama’s campaign recruiting tool app coming in at ~$100,000
However…
While these posts provide a singular answer, they do not provide insight into how the different components and considerations of development amalgamate into an app’s complexity, and thus the time it takes to develop an app, and thus how much it costs to build an app. Without understanding these different ingredients, it may be a frustratingly opaque experience for business decision makers when glancing at the final bill. That’s why we wanted to take a moment to explain some of the general factors affecting app development, so that business decision makers like you can be prepared with the knowledge of what factors cause your app to be more (or less) expensive to build. Knowledge is power, and team Incipia is in the business of empowering people, regardless of whether it is through the act of educating, building, marketing or another medium.With that said, please keep in mind that: A) in practice, how these factors play out is also affected by context such as infrastructure (e.g. are the right RESTful database hooks available), B) this article is meant to be educational, rather than definitive and C) the perspectives in this series are our own, based on our experience and what we know.
This is part 1 of a 2-part series and focuses on an app’s underlying functionality and internal “guts.” Part 2 will cover how the context that an app must fit into can affect the cost to develop it.
Before diving in, we want to cover a common misconception, which is that apps that have fewer screens cost less to build. While the number of screens that an app contains is often used to determine the cost in UX/UI design terms, the same doesn’t necessarily hold true for development terms. Rather, the functionality called for in an app’s specs (regardless of how many screens) is a much more accurate indicator of the time involved to develop an app, and thus the cost. For example, a video conferencing app that has only a few screens would nonetheless be expensive to build, given the time it would take to develop and properly test things like the backend for managing user accounts, the network plumbing to initiate, maintain and end calls and a system to optimize calls that encountered problematic connections.
One more preliminary item we want to cover is that, while there are hybrid/cross-platform technologies like Xamarin or Phonegap that allow developers to program once for multiple platforms, cross platform apps encounter a trade off the user experience and time (cost) to develop. Fellow mobile app studio Ymedia Labs offers a deep dive into the native vs hybrid debate for those of you curious to understand the differences in more detail.
*That said, Unity has emerged as the hybrid technology exception, being embraced by game developers for investing significant effort into producing a quality cross-platform experience dedicated to the game niche of apps, which allows it to specialize research and development to further refine the technology.
Factor #1: The number and scope of functionalities required
The time it takes to properly develop or integrate functionality for an app will naturally affect how long it takes to develop. The most inexpensive kind of app is one that does not require significant investments in building or pulling in any functionality (frameworks, SDKs - software development kits, APIs - application programming interfaces, etc.) in order to operate; but, given the diverse needs of both businesses that invest in apps and their customers, nearly all apps will require different functionalities to work properly, whether built custom or externally-sourced. Pulling in external functionality precludes the time to build it from scratch, but still requires material work of adding and managing the functionality. Here are some of the most common functionality integrations found in apps:#1 Managing user profiles
Managing user profiles requires a backend database in order to store, edit and retrieve information for each user that signs up, as well as keep track of a user’s engagement history within the app. There are multiple ways to implement user profiles, ranging from more to less work on the part of the developer, and costing more to less per app user. For smaller apps, it’s more feasible (from the initial development time/cost involved) to use a backend service like Firebase, which removes the work in programming the user profiling system from the developer’s plate by handing them an SDK that they can hook into the app to manage user profiling.
However, these types of services charge more for this convenience and run the risk of shutting down like the recently deceased Parse. In order to build a system that can scale to hundreds of thousands or millions of users in a cost-effective manner, it’s better to invest more in the short-term to custom build the user profiling system of an app using a backend service like Azure or Amazon Web Services, or even better using a simple Linux or other kind of server backend.
#2 Handling e-commerce transactions
Adding the ability to make purchases within an app will increase the costs to build it because this not only requires building or integrating a SaaS (software as a service) system like Stripe to handle charges, but it also puts more responsibility on the developer to write robust code to surround the entire payment process. Managing customer payments increases the stakes if things going awry (e.g. preventing surprise charges or mistaken decimal placements) and requires developers to develop a robust system that can handle any errors gracefully in order to protect the user experience, all while ensuring that payment security remains rock solid.
#3 Social integrations The phrase “let’s include x integration with y social network!” = more work for an app developer. Building the ability to pull data from or push data to social networks is often times deceivingly more work to implement than one would think, and is largely dependent on the quality of documentation available on the social network’s framework and APIs (APIs are what apps use to “talk to” a social network and pass data back and forth); it’s pretty shocking how terrible some of the developer API documentation is for some of the largest companies (e.g. Google, Twitter, etc). Additionally, some functionalities are easier to implement than others (e.g. posting content vs sharing an invite) and some social networks make certain functionalities easier than others (e.g. sharing content to Twitter vs Instagram).
While some areas of app development primarily involve pushing and pulling data from an app via social web APIs, there are other situations that operate at a much deeper level of complexity. This goes back to the point of functionality, rather than number of screens being a much bigger indicator of the cost to develop an app.
A quintessential example of such deeper complexity technology is video and image editing (e.g. applying a graphical modification to a live video feed), which can quickly become a heavyweight in development time. Frameworks (compartments of code that perform a specialized functionality) that provide API’s for image and video handling are inherently more complex to work with, and often require the knowledge of developers who have a rich understanding of manual memory management. Essentially, to build an app which makes heavy use of handling image and videos, yet is also quality and performant (i.e. doesn’t take forever to load video/images) can require one or even multiple developers skilled in visual processing, which will significantly increase the total costs to build an app.
#5 Dynamic vs static data
If an app’s content is derived from an external datasource via an API, it will take more time to build, as opposed to an app that has all the information it needs on its own. One of our apps, Sigma stretch is an example of a static app because it contains all the pictures and text necessary to operate within the app bundle – when the app launches for the first time, it does not need to download any content from an external server (this was optimal as users worked in areas of low internet connectivity). If we were to extend the Sigma Stretch app to pull text or images from a server, this would change the nature of the app from static to dynamic. Apps that involve e-commerce, user profiles (e.g. social networks) or networking (e.g. video conferencing) all involve heavy use of dynamic data sources.
Furthermore, with a static app you can assume that the data will always be available because it’s in the app itself; but with dynamic data there is always the possibility that the data source is unreachable. In order to prevent crashes that could result from problems pulling or pushing data, a developer must spend time building extensive error handling logic to reduce and gracefully handle issues. On the topic of additional testing costs, bear in mind that:
Crashes are the #1 cause of low ratings, and low ratings kill apps.While the testing phase may sometimes be a tempting place to cut costs, this is highly inadvisable because bugs will arise in virtually every app made, especially so in apps that involve more complex functionality. Even apps created by fortune 100 and top tech companies have bugs - just have a look at any app’s developer history log and note how many bugs are fixed from version to version.
Rather than as an expense, think of good testing as an investment. It will cost more money to develop an app that includes proper testing procedures such asunit tests, but those procedures could mean the difference between a feature staying on schedule, launching with bugs or being rolled into a future release.
Also without proper testing, making changes to a complex codebase will likely result in something breaking that isn’t noticed right away and which becomes exponentially more difficult to fix, the longer it goes without being discovered.With complex apps, even fixing a bug in one area of the code can cause something in another area to break and produce a new bug, which is why unit tests are particularly important: when something breaks, unit tests raise an immediate flag. This is vital for a product’s entire roadmap because additional functionality could have been built on top of a buggy foundation, which will cause a much more widespread issue.
#6 Add-on SDKs
There are hundreds, even thousands of SDKS that enable marketers and product managers to optimize an app, from A/B testing, to data analytics, to push notifications and CRMs. Adding these SDKs can range from simple in implementation (tracking app installs) to complex (tracking the top 10% of people who have utilized a particular in app purchase item). Some services likesegment or mparticle help alleviate this issue by allowing a developer to install one SDK and use server-to-server communications to push data to supported services.
This diagram from Mparticle provides a nice visual breakdown of some of the different types of add-on SDKs.
Factor #2 Data models: their mutability and interconnectedness
Data models are the underlying structures that enable users to interact with an app and input or access data within it via the app’s UX (e.g. tabular navigation) and UI elements (e.g. search field). Think of data models as the stations in anassembly line (the app), where each station (data model) is connected to several others and has a different job (set of functions which display and or mutate a user’s data). For example, the station at the start of a social networking assembly line will allow a user to either sign up or log in, and will subsequently direct the user next to either the “create a profile” or “news feed station,” where the user will then be able to access new functionality and other stations.Just as complex assembly lines require extensive time to set up each station and tool it just right, so too do complex apps where many data models must be 1) created with the appropriate functionality to properly display and mutate the data they receive, and 2) connected with the other data models they must interact with. Here is an example of what the logic governing a generic sign up procedure looks like:
At Incipia not only do we build and market our own internal mobile apps, but we are also available for hire as a full service app firm to help companies design, develop and market apps. For inquiries, please fill out our inquiry form or email us