When we first wrote about the real cost of a mobile product in 2018, we gave you the estimated budget a startup would need to build, launch and grow a mobile product for 12 months.
Three years later, the question: ‘how much will my product cost?’ still pops up insistently in our conversations. We’ve heard it asked in an excited, frustrated, or worried tone of voice.
So, we’ve decided to update that piece and include some updated numbers but also an updated process that we’ve validated further in the last 3 years.
And even now, if the conversation starts from ‘we’re building a dating app, a marketplace, a learning app’, we can’t really say a number at that level of understanding. Even if we’d give a budget estimate, that would be the wrong number to focus on, as the real cost to develop, launch and scale a mobile product is about more than the initial product development and way higher than the cost of having the v1 of the app built.
What founders should know before asking about costs
What building an MVP really means
Since we’ve started building mobile-first products in 2013, we’ve talked to thousands of founders. Many seemed confused about the goal of an MVP and how much they should build when they first start out.
And we get it, really. The term has been around since 2001, and everyone who is someone in the startup world is throwing this word around with a different weight attached to it, and there’s a lot of pressure to get it right the first time around.
But here’s the thing.
What the theory says matters only to the extent it gives you some mental models and frameworks to navigate this journey you’ve started.
But here’s what matters: your product vision matters, and the problem you’ve set out to solve matters, and how you’re going to solve some real-world needs with your product matters.
Think of an MVP as the first iteration of a problem-solution fit hypothesis. It’s something you put in front of some core users (a minimum viable audience?) in order to test whether a certain behaviour will happen around and within that product. We use an MVP in order to test a risk, very early on and with the smallest investment possible. In other words, we build a first version of the product to test its ability to deliver value to some users (does it get a job done for them?), test your business model (if it gets the job done, are users paying for your product?) and by that give you either validation or learning.
With this approach, we realise that a version of the product can be called an MVP only if we have a validation plan that comes along with it. Otherwise, it’s just a product we can afford at that stage. And there’s a big difference between the two.
When you approach your MVP with the mindset that it’s a hypothesis to be tested, there are a few implications:
- You’re not overbuilding; you’re building exactly the right product to test what you need to see in the market, and that’s dictated by your users’ needs and your existing competitors
- It’s perfectly fine and expected that you pivot or change focus along the way, once you have more information about how users interacted with your proposed value in the product.
At the end of the day, it’s really smarter to build the right product incrementally, than to build the wrong product with a bang.
Validate your product before building it
Counterintuitively, testing your problem-solution fit is not a two-door option of ‘build MVP’ or ‘give up’. In other words, you can and should do a lot of product idea validation before you launch an MVP. In this Idea Validation Handbook, we’ve gathered here a list of options you have to test a product idea before you build any form of the product.
And there is another way, that follows the idea validation step. It’s about using other tools and platforms to test the core value proposition of the product without properly building your own.
Here are some examples of validating product concepts without building your own custom MVP.
Wellory tested their anti-diet nutrition product matching coaches and clients via a limited SMS service to gauge interest for their product.
Oxwash built their first laundry service in Oxford and built their delivery service with third-party web services to get the business running locally to generate their first revenue.
DEMI creates communities around food for people who enjoy sharing their passion. They’ve tested their idea through Whatsapp communities before setting out to build and launch their own product.
Otherwise, if the product involves highly complex technical architectures or features, instead of building the full MVP, de-risk the building process through a proof of concept (POC).
It may sound rather weird that a product building studio would advise building less, as we make money by building more. But here’s the catch: we have no intention of making money from dead companies!
We’d rather earn less at the beginning from our product partnerships, but help our partner startups survive in the market, up to a point when they get to Product-Market fit and start scaling for real. Survival is the name of the game here and we’ve aligned all our operations to de-risk your product investments at different levels and be a product partner for the long run.
How Tapptitude de-risks app development
So what’s our process in helping our clients re-risk product development?
We encourage our clients to reframe how they think of their MVP. Many believe it either means:
- The least functional version of my product I can build, with nothing that will make it lovable
- The minimum commercially viable version of my product that I can afford, which means I’ll put in all the features I think might be useful for the users
The sweet spot is right in the middle. A great MVP is one which:
- Has the fewest features needed to provide the right mix of functional, usable and a little bit of lovable
- Tests a hypothesis of delivering value to their users, meaning it solves a problem for them and creates a certain stable behaviour
- Eats up as little of your budget as possible, so you can keep iterating on the MVP, informed by real learnings that come from actual usage of the product and qualitative user feedback.
When you set out to build an MVP with our team at Tapptitude, we work with you as a hands-on and full-function product partner, to support you in better defining your problem space, the audience you’re addressing, the core user flows that would help you deliver value, and how to translate and prioritise these into product offerings. We try to stick to a version that can be built within a timeline of 2.5 to 3.5 months.
If the estimated timeline ends up longer than that, you might be in one of two cases:
- We are building too much, too early
- We are building in a competitive landscape where user expectations are very high and we’ll need to meet them to be attractive to them (e.g. the healthtech or fintech space)
And finally, we get to the real question here:
‘How much money do I need to have when I plan to build a world-changing digital product?’
The 12-months budget of surviving with your startup
First of all, let’s expand the question a little. After all, if you’re thinking of building a product, you’re also aware that you must have a business set up and think of ways to go to market with the product once it’s live. So the real question is:
How much budget do you need for a 12-month runway for your startup?
We’ve partnered with over 120 clients in the last 7 years, to support them in building their product concepts and we’ve seen quite a few things around how you need and need not budget your product investment. Based on this experience, we can share with you averages of what this could look like, to help you in your planning as well.
Think of these numbers as a framework rather than anything else. Some may be more complex, some may need less initial investment, so this article won’t help you escape the process of defining and budgeting accurately your product. Instead, it should help you with the very early stage of budget planning.
The components of a startup budget
- Product definition
- UX/UI Prototyping
Building an MVP
- First Product-Solution Fit hypothesis, 1 Platform Native
- Tools, 3rd Party Platform, Hosting
Post-MVP Iterations or Scaling
- 6 months of calibration OR duplication to second platform
Third Party Tools
- Operations + Anything else
Step 1: Concepting
Product concepting, or what we call the Product Definition Phase, is where our skills as product strategists step in. We encourage every client we work with to start their product journey with market research done beforehand, either by themselves or through contracted work. But having an understanding of the market or of the users is only the first part of the process.
The next part is something we usually do together, through a series of workshops where we align on defining:
- the problem space
- the audience who has that need
- what competitors exist in that space
- What alternatives exist in that space
- How you can create value in that space
- How to frame that value creation into a business model (through a Lean Canvas)
- How to translate that value into the product as users experience and features
- How to prioritise product offerings
Once these things are defined in the workshop sessions, they come together in two forms:
- A Product Requirements Documentation
- A Product Prototype (with wireframes or final UI designs)
Here at Tapptitude, we focus a lot on prototyping with wireframing before we jump into final UI and product development, as it is faster and cheaper to test and decide what will go into the first iteration of the MVP.
After the wireframes are agreed upon, we go into creating the UI design, taking the product closer to its final visual style and adding that specific brand personality and the user experience we want to it. After we have the app screens designed, we usually create an interactive prototype of the mobile app, so that we have a clear feel of how the user will experience the product.
If we also want logo creation and a proper visual branding project, your budget can jump by a few thousand pounds. When the focus is rather on validating the MVP, we usually include a simple identity pack in the design (covering the brand identity and app store icon).
Step 2: Building an MVP
Once we have the product discovery done, we know what kind of MVP we want to launch. Having the UI designs ready allows us to make an accurate budget and time planning for the development team. In truth, this is where you will get the best estimation of how much it will cost to build your app. One decision you will need to make is to decide which mobile platform to start with. Usually, our recommendation for the MVP stage is to do the hypothesis testing on only one platform first, either iOS or Android, whenever possible.
Here, we do things from the bottom-up: the allocated product team would analyse the product documentation and interactive prototype and do the development estimate, feature by feature. We end up with a document where we know how much time we estimate on each area of functionality, therefore, the final estimate for the product development in terms of time. Apply for the rate card, and we also have the budget needed to develop the full-stack mobile product.
For our example, let’s say we have the following estimates:
iOS app or Android app
We’d need 10 to 12 weeks to code and launch an entire native iOS app or native Android app, for a resulting budget of around $70.000-$87.500. We use the latest version of Swift for coding native apps on iOS, or Kotlin for Android. Testing is also budgeted here, as well as product management and some product strategy.
Backend, APIs and Web Admin
For the web admin, we will use HTML 5/ CSS 3/ JS and AngularJS + Bootstrap as frameworks, while for the backend we will go with the js stack: node.js for the API and Mongo as the database. We also use AWS with Heroku for cloud storage.
Step 3: Post-MVP Iterations
You’ve got your MVP launched on the market, well done!
Depending on how it performs (and you’ll have to give it a bit of time here while you grow your user base), you have two options when it comes to future development.
Spend the next 6 months calibrating the product you already have to improve it, working with real user feedback and usage data.
Operationally, this means you’ll set up a way to gather user feedback and product analytics. You will keep working with your product team at Tapptitude to prioritise requests, identify issues, and define, design and build new features to integrate into your product as new versions are released.
Duplication to a second platform
If you’re happy with the results you’re currently getting, you may decide to duplicate your product to the second platform, to increase your chances of funding or your revenue stream. In other words, if your MVP was built for iOS, you’ll now build the Android version for it.
Expect the team to go over the designs and estimations again, and some changes to your budget. For example, backend costs may go down (as you already have databases built, you’re only scaling them), but testing costs may go up (especially if you’re building an Android product, a platform that has a bigger variety of devices to test for).
Beyond launching the first version, there’s also a product management challenge in maintaining and upgrading the apps for the two platforms in the long term. Users will expect parity between features; you as the startup will need to generate funding or revenue to maintain and upgrade both apps and the backend supporting the products.
Whatever option you go for here, keep in mind that building a product is just the first step in a long-term commitment of maintaining it, upgrading it, and most importantly, listening to your users as you do this. With this in mind, your budget for post-MVP iterations should be close to your budget for building an MVP.
Step 4: Go-to-market and 1 year of marketing
It’s really difficult to put a number in this box, as things can vary a lot, based on the business model, competition, market category, user acquisition cost and cost of talent etc. But in our experience, the safe bet would be to secure a budget of around 25% of your 12-month runway costs in order to launch the product and move towards product-market fit. Hopefully, our product will have a viral mechanism and great engagement. These will lower our user acquisition cost, but there still needs to be some Go-To-Market and user growth budget.
Other things that might end up being covered by this budget that you wouldn’t expect are legal and financial issues (e.g. user privacy, compliance audits). In most cases, it’s cheaper to just bring in an expert rather than figure out things for yourself.
Step 5: Tools, 3rd Party Platforms, Hosting
The last point on our list are tools, third party platforms and hosting for your product that you may not think about in the early days, especially as a first-time founder. As a personal user, many of these services are available for you for free, but the moment you switch to becoming a business client, both your profile and your needs change.
So while this section of the budget covers only 5% of the 12-month runway, it covers all the tiny wheels that make sure your company and your product can keep turning:
- AWS hosting, website hosting
- Third-party subscriptions for your product (analytics tools, email and notification automation tool, payment channels, a billing software etc.)
- Third-party subscriptions for your company (business email, CRM, marketing stack, etc)
How much will my app cost?
As you can see, there’s more to the question of: ‘How much will my app cost?’ than the development cost. After all, if you’re getting in this to build a business, your budgeting should reflect that as well. And that means including a budget for concepting, building, iterating, marketing, and all the tools that keep the business running.
So let’s sum up these estimative numbers.
|Budget category||Percent||Min. Budget||Max. Budget|
|User Concepting (Research, Product definition, UX/UI Prototyping)||10%||$20,000.00||$25,000.00|
|MVP (First Product-Solution Fit hypothesis, 1 Platform Native)||35%||$70,000.00||$87,500.00|
|Post-MVP Iterations (6 months of calibration OR duplication to second platform)||25%||$50,000.00||$62,500.00|
|GTM, Marketing + Anything else||25%||$50,000.00||$62,500.00|
|Tools, 3rd Party Platform, Hosting||5%||$10,000.00||$12,500.00|
Keep in mind that these numbers reflect an estimation from our experience of working with over 120 client partners across almost 8 years. Depending on the complexity of your product, your actual budget may go down, or go higher. You’ll only know the most accurate numbers once you’ve gone through a Product Definition Phase (or something similar) and have a clear prototype of what you want to build.
Turning a mobile product into a sustainable business is a harder, longer and a lot more costly process than it would seem initially. And as you can see, the cost of the initial product development is only around 35% of the total budget you need for your product for 1 year with an additional 25% for post-MVP iterations. The total budget for keeping a mobile product in the market for 1 year needs an additional half of that to give your business the best chances of survival.
Your startup journey is not going to be linear, and that’s ok. It’s better to build incrementally and to keep pivoting until you get it right. It’s even better to scrap everything early and keep the money to try something different in the same problem space if you conclude that the risks are too high to continue.
In the end, being in love with the problem you’re trying to solve, getting comfortable with finding things out incrementally and with a given threshold of risk is what makes this journey worth it. And having the right partner on your side can make it an easier road to travel.