Imagine you wanted to build Instagram, an app with one billion active monthly users and a technically complex functionality. How much does it cost to build an app like Instagram? Well, if you wanted us to make an accurate estimation, we'd send you a document with six zeros in it. A high-load application like Instagram requires a huge budget.
Luckily, not all apps out there cost that much. There are other types of project that require less money to develop. For example, a few months ago we built Creator Connect, an app that looks like Instagram but targets artists and those interested in buying art. The app is a minimum viable product or MVP. By this, we mean that the app contains just enough basic features to keep users happy and to provide value. Creator Connect allows users to register, upload new photos, view artworks in the news feed, write comments, send messages, and buy and sell art.
From a technical standpoint, it uses Amazon Web Services for the backend, GraphQL for the API, and Amazon S3 as data storage.
We spent eight weeks building this project. This iOS app development cost was $60,000.
A prototype for Lux Group, one of Australia’s leading e-commerce groups, is yet another mobile app development project where the cost differed greatly from the app prices above. The prototype is a redesign of Cudo, an app that sells the best offers for dining, entertainment, pampering, and adventure experiences in every major Australian city.
We spent two weeks building this prototype. In addition to the functionality Cudo offers, our prototype also includes some new features such as one-click purchasing, personal recommendations, and a simplified UI flow. We used React Native to develop this prototype for both the iOS and Android platforms. It has no backend, and all the data is mocked up. The application includes UI animations and all the screens required for the purchasing process. So, how much does it cost to build an app prototype? The one we created for Lux Group cost around $4,500.
The app development price of the three projects we’ve described above differs greatly. Why is there such a difference? And how much does it cost to build an app in Australia in 2019?
Now, you might say that the price differs because there are different features in all those apps. And that initially sounds pretty reasonable.
But in fact, the price of an app has less to do with features and depends much more on which phase in the product development lifecycle the app is in, and on what purpose you build it for. For example, you might need a prototype to make your idea tangible so your investors could understand what you want to build. Or, if you decide to create an MVP, you might need to test your idea on the market first, and then work further on the development of a complete product. The three apps we looked at above are examples of three phases in the app development lifecycle.
Mobile app development cost depends on which phase your product is currently in. To deliver it to market in the fastest and cheapest manner possible, you need to iterate. Now that’s set out, let's explore the phases in the product development lifecycle and see how much you should expect to pay for an app at each phase.
Below is our version of an app cost calculator. It tells you the price of an app from a prototype, to an MVP, to a full-featured product. What do you need to make an app in terms of functionality, distribution, technology, and a development team? Let's find out.
This is how much it might cost to build an early app version. Let’s call this version a prototype. For $1,000 to $5,000 you can buy around 20 to 100 app-developer hours, assuming your developer charges $50 per hour. What you can implement within this time? Not so much really, but this might be exactly what you need to get the product out the door.
You should not expect a full-featured product within this budget. The main purpose of a prototype is to materialise your idea. A prototype is something you can open on your phone and show to your investors.
Usually, a prototype does not have enough functionality to deliver to end users. (Unless you use Firebase or AppSync to move the data from the database to the app). But it’s an amazing way to pitch your project to investors or start testing your idea in a closed focus group.
With a prototype, you can easily demonstrate your idea and significantly improve your chances of getting the needed funds. As you know, a picture is worth a thousand words.
A prototype is usually distributed in a closed beta group whereby special invitations to install the app are delivered.
There is a TestFlight beta testing option for iOS. It allows you to add up to 1,000 beta testers and send them the app bypassing the App Store. The app should still pass through the review process, but this process is not as strict and allows you to distribute unfinished, prototype apps.
Google Play Store offers more ways to distribute your prototype. Using Google's Internal tests you can quickly send the app to a specific group of people. Closed test release allows you to reach a large group of testers and the Open test release makes it possible to distribute the test app within the Play store itself.
Cross-platform frameworks are an amazing way to build a prototype. We love React Native and are now looking to use Flutter as well. But you can choose whichever technology your developer has the most experience with; there is no time for learning new tools and the budget is extremely limited. As a result, efficiency is king.
React Native is an amazing way to prototype mobile applications because it has a huge number of components and libraries. Building UI in React Native is fast and easy. And the prototype can be distributed to both iOS and Android platforms.
If you still need some backend and a user-identity system (for example for registration and login), a good idea is to use a ready-to-go SaaS service, such as firebase/firestore/firebase auth or AppSync/DynamoDB/Cognito/Amplify. These services allow you to start and run a basic backend within just a couple of hours.
Different projects require different skill sets.
For example, Facebook has one of the best app development teams on the planet. No doubt about it, this team is able to implement your project. But is it going to be time and cost-efficient? Probably not, because this team is focused on delivering high-performing bug-free apps that can withstand huge amounts of traffic, and will spend lots of time and money to do that.
It's like commuting to work on Uber with Lewis Hamilton, the F1 champion, as a driver. Definitely, he can drive you there, but this ride will cost you much more than a ride with a regular driver. And Lewis won't get you to work any faster, even though he is the fastest driver on the planet, because he has to obey the same road rules as everybody else. The same speed limits and traffic lights will apply. In fact, it’s more likely that a regular Uber driver will get you to work faster because he has more experience driving in a busy city and knows the shortcuts.
For an app project at the prototype stage, the most important criteria are rate and efficiency. You might feel that using the cheapest developer is a good idea, but in general, the reverse is true.
If you read the IT management iconic bestseller, The Mythical Man-Month, by Frederick Phillips Brooks, you will find that the productivity of an outstanding developer sits around 20 times higher than the productivity of an average developer.
Obviously, not all expensive developers are good and not all cheap developers are bad. But the rule “What you pay for is what you get” works pretty well in the app development industry. Don’t be afraid to hire a developer who costs double what another developer does if you know he is good. As a result, you might get 20 times more output for the same amount of time and money.
This is the average cost of an app which is at the minimum viable product (MVP) stage. There are lots of definitions of an MVP. This term is a concept from Lean Startup, a methodology for developing businesses and products. Eric Ries, the author of Lean Startup defined an MVP as that version of a new product which allows a team to collect the maximum amount of validated learning about customers with the least effort.
An MVP is a functional product. It should be able to solve a problem for the end user and focus on a minimal number of core app functions. For example, if you are creating a marketplace, it should provide payments and related processes. If you are making a social app, it should allow users to connect with each other.
As a product owner, it’s your responsibility to identify the core features of an MVP. It's not easy to identify this feature set because everything seems important. But try to ask yourself if your application could exist without this feature or that feature, and you will quickly find your core functionality.
For example, could Instagram exist without stories, comments, likes, shares, and direct messages? Absolutely. And what about image filters? Could Instagram exist without them? Obviously yes, but in this case it wouldn't be Instagram. Filters are Instagram's killer feature and something that drew the attention of users from day one.
MVPs are hard to implement because of the limited budget, time is a critical consideration as well. But the hardest part of all is excluding features from the product which are not critical for an MVP.
Creating an MVP involves the same areas as regular app development does: frontend, mobile apps, backend, quality assurance, analytics, and support. But everything should be reduced as much as possible.
Check out a real-life success story about this process in our article 10 steps to create MVP in 6 weeks.
The distribution of an MVP very much depends on the type of the project.
If you are creating a MedTech project, for example, it’s a good idea to have the MVP released in a closed group of testers. The cost of mistakes in this area is very high, so it's better to use a safer distribution strategy.
If you are creating a mass-market product like Instagram, the best strategy is to make a public release. Just keep in mind that the app should follow the App Store's review guidelines. Check if there are no “coming soon,” “beta” or “not implemented yet” parts in your app build.
There are two main strategies for an MVP, let’s take a look at those now.
Strategy one: Validate the idea
If you choose this strategy, you need to get a sufficient number of users to prove that the idea works. You then get a good investment to allow you to continue building the product further.
With this strategy, you should remember that an MVP is not scalable. And you should be ready to create a scalable, real product as your next step. Why not create a scalable product from day one?
Because creating a scalable MVP requires around 30 to 100 per cent extra time and resources during the initial build. Usually, MVPs are financially supported by personal funds, and most people simply don’t have enough money to create a scalable product from scratch.
Don’t worry, you have to focus on your goals for this MVP stage. If your product doesn't get the “product/market fit,” you don’t need this scalability. If your idea gets a product/market fit (and I really hope it does), you will need some time to reimplement the MVP functions in the release app to make your product scalable. And this time you will create a better app because you already have knowledge of your market.
Technology wise, the best choice for strategy one is a cross-platform framework like React Native or Flutter. Don’t try to be perfect with your cross-platform MVP because if you are trying to implement custom components with React Native or complex animations, you will spend a huge amount of time. Just use the features available out of the box and try to avoid building custom elements. Focus on how the MVP can solve the core problem for the end user, but don't pixel perfect the implementation of the design.
For the backend you can also use serverless services and ready-to-go SaaS platforms like firebase/firestore/firebase auth or AppSync/DynamoDB/Cognito/Amplify. You can extend the possibilities of these platforms with custom business logic using serverless functions or AWS lambdas.
Strategy two: Move fast
Sometimes, you don't need to validate the idea. You already know that your product will work. For example, there are many local entrepreneurs who used Uber's business model to created a mobile app that allows people to simply tap their smartphone and have a cab arrive at their location in the minimum possible time.
If you want to develop a product with an idea that has already been tried and tested, there is a high chance that many other entrepreneurs are thinking along the same lines. For this reason, you have to be the fastest. You don’t have the time to rebuild your MVP and make it into a scalable, full-featured app. In this situation, every day counts, so the best strategy is to focus on a building a scalable MVP from day one.
This strategy requires you to choose the most sustainable, flexible and extendable technologies so you can easily scale the product down the road.
Native technologies are a good option for such mobile apps. You will also need a full-featured backend with staging and production environments. Quality assurance cycles with manual and automated tests should be involved as well.
With all these requirements, strategy two can greatly increase the cost of app development. But there are ways to avoid that. Limit MVP functions, or go with an iOS platform only and postpone Android and web apps for the later stages.
An MVP is an extremely challenging project because of the strict time and financial constraints. Quite often it’s too complex for one developer and requires a whole team consisting of three, or even nine, specialists. In which case, the app development cost depends on the productivity of the entire team, not a single specialist.
In a productive team, everybody is on the same page. They share common goals, follow the same processes, are aware of all technologies used and communicate daily with each other. One slow developer can be a bottleneck and slow the whole team down. And poor communication can kill the project from the outset.
When you try to choose the right team, always refer to their previous experience working on MVP projects. Figure out how accurate they were with deadlines, how experienced they are with technologies and how well they communicated during project implementations.
An outstanding team can be 100 times more productive than a bad team, even if the bad team has good developers in it.
This is the amount of money usually needed to build a full-featured app. This product could be the next step after an MVP. Or it can be an app for an existing business. For example, we built a project like this for a transportation company who wanted to improve their logistics processes and driver experience using modern technologies. You can check out our Atlas case study to learn more about how we developed it.
The $150, 000 to $400,000 budget isn't sufficient enough though for some technically challenging projects that involve R&D, AI or crypto.
A full-featured app doesn't usually have strict implementation constraints as far as functionality is concerned. These products offer a full feature set for the end users. Sometimes they can even have some A/B testing.
To build this type of mobile app, you need to get analytics, crashlytics, and CI processes involved. You need to have a solid backend with monitoring and an automatic alert system in case of violations. Your backend also needs the ability to automatically scale with increasing load.
You also need to write automated tests so that the system has can validate each new commit, and let the developer know about issues immediately. The whole system should be reliable and secure.
Usually, this type of app works on all platforms including iOS, Android and the web.
The app should be distributed through the main official app stores: Apple App Store, Google Play Market, Amazon App Store and other region-specific stores.
The project should have a beta version release system to test the staging implementation before the final release. You can do this with TestFlight and Beta Play store.
There are no strict limitations for a tech stack. Obviously, you should not try to reinvent the wheel. But try to develop a custom backend with specific business logic at the fore. Keep in mind that your app should be able to extend and scale in other geographic regions.
The best choice for this kind of project is native apps. Cross-platform solutions may sound good, but when you dive into the real developer experience, you will quickly understand how hard it is to maintain a cross-platform application when its complexity starts growing. A good example is this amazing experiment undertaken by the AirBnB dev team.
With a full-featured product, you will normally have a bigger user base than with an MVP. These people expect the app to work perfectly. The risk of releasing an unstable product and losing customers as a result is much higher than with an MVP, which nobody expects to be ideal. Therefore, stability is critical with full-featured apps.
Your app should be ready to scale and handle high loads when it becomes more popular. Scalability is critical as well. Using stress-tests you can stimulate high user traffic to find any performance bottlenecks.
The most important requirement for your app developers at this stage is to have a strong team leader. His or her job is to create proper infrastructure and architecture and guide the team to follow the development plan. With an experienced team of developers who can implement the architecture that the team leader planned, your project can be completed within the estimated time frame and budget.
There are three types of projects that could be included in this category. These are:
An app that costs $500,000 or more should have all the functionality you need. You can expect full test sets, Continuous Integration, test automation, monitoring systems, admin portals, management systems, reporting, A/B testing, some technically dense custom solutions that involve artificial intelligence, crypto, R&D processes, and even more.
The released app should be distributed through the main app stores. Usually, a complex app has a staging release for testing new features. You can also expect to have releases for closed testing of experimental features. A good idea is to have alpha and beta release cycles for big projects, but this requires a dedicated QA team.
If you are creating a corporate app for internal use, you can apply for an enterprise development program from Apple or Google. With this program, you can distribute your apps bypassing Apple and Google's infrastructure (App Store, Testflight, Play Store).
The best choice for apps within this category is native app development. It allows you to use the most recent platform features without depending on third-party systems like cross-platform tools, and increase the overall stability of your product. The tools that increase stability and performance are a good idea as well. These include A/B testing, user analytics, crashlytics, monitoring, review system, customer support, funnel engagement, internal marketing and targeting, and much more.
Your backend should be focused on breakage resistance and stability. No software is 100 per cent bug-free and even the most expensive piece of hardware can break. Therefore, you need to build the backend in such a way that even if some parts stop working, the whole system will continue to work.
There are hundreds of tools for that. We prefer to use Golang as the main language for high-load systems, basically because it is created for high performance and scalability. Compared to NodeJS, Ruby on Rails, and PHP, Golang is compiled to native code for your server.
This type of project requires a team experienced in your specific area. Specification matters a lot if we are talking about R&D projects. For example, at MadAppGang, we have a dedicated mathematics engineer to solve specific tasks in artificial intelligence and cryptography.
One more critical requirement is team sustainability. It’s extremely hard to find a team that is able to create a complex project from scratch. But it’s even harder to find a team that can continue to improve upon an existing project.
This app development cost breakdown is just an overall view. Each project is unique and there is no general way to describe all the possible scenarios and budget ranges. But I hope this article helps you to understand what you can expect from the budget you have and what the estimations you are getting from app development companies actually mean.
I hope you don't believe in the miracle stories that abound about John Average Smith creating an app for $1,000 within one month with a magical developer from a far away and poor land. More often than not, these are just fairy tales. Personally, I believe there’s always room for a miracle. But I don’t think it’s a good idea to rely on that.
If you are not a technical person, you probably find app development process overwhelming - and they often are. But you can hire a technical team lead to help you deal with the complexities. At MadAppGang we provide technology consultancy services and will review your application with pleasure.