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.
Functionality
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.
Distribution
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.
Technology
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.
Developer Requirements
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.