How much does it cost to build an app?
Not all mobile applications costs can be easy to predict. Let's look at costs associated with prototypes, minimum viable products, and complex application builds.
by Rob Hassler
When I ask my realtor, “how much does it cost to buy a house around here?” They’ll tell me, “it depends.”
That’s not what I want to hear. Sigh. But they’re not wrong.
When you ask me some form of, “How much does it cost to build an app? How long does it take to develop an app? What does app design cost?” I want to channel my realtor, but I will cheat and try to offer at least a rough cost model for building an app:
What does an 'MVP' look like?
“MVP” could mean different things to different people, just like the words an “average townhome" might mean different things to different people.
But I’ll try to break down what I think that means to us:
|Clickable Prototype||MVP||Complex App|
|What is it?||A set of designs that illustrate how your app is going to function. It will allow users to click around.
The substance is a series of images; no coding is involved at this point.
|The minimum set of features that allows your early adopters to use the core concepts of your product.
Typically this is the first version of your product to be released to the market.
|App with a lot of features for multiple users.|
|How long did it take to develop?||A few weeks||A few months||7-9 months|
|How many people?||1 FTE UI/UX Engineer||2 FTE Engineers
1 FTE UI/UX Designer
|3.5 FTE Engineers
1 FTE UI/UX Designer
|How much "design" does it involve?||Lot of emphasis on the user flow and experience.||Lot of emphasis on the user flow and experience for primary user.
Little emphasis on aesthetic design.
|More emphasis on user flow for secondary users.
More emphasis on aesthetic design
|Ready for||You to show potential customers and friends to validate your idea.||10-15 key customers to start using for free.||50-100 customers to start using and paying for it.|
Here’s what it might look like:
These sketches illustrate how the app is intended to flow from beginning to end for one specific user need. The sketches allow the team to iterate on the flow and concept more inexpensively than iterating in code.
Minimum Viable Product
The screens below show what the early version of this product looked like. You may notice modest evolutions in the flow; now there is a step to sync and choose “fan decks” before measuring a color.
The app now has many more features that satisfy other user types; it includes basic color identification features that help painting contractors and new features that help architects and interior decorators create, match, and share color palettes. This version also includes a new admin portal that allows distributors of this device to see where it is being used and which colors are most searched.
Sacrifice features not quality
I want it all: THAT house. With ample square footage. AND a stellar neighborhood. AND the highly rated school district. AND the slick kitchen lighting. I salivate over THAT house.
I also can’t believe how cheap it is. There’s an angel on the left shoulder suggesting, this is a sign; just buy it already.
The angel on the right is forecasting remorse when I finally realize the construction quality is poor; go with the other house with little less square footage and a little more integrity.
This sentiment very much exists for building an app. The good news is that people are starting to talk about it more.
The mantra “move fast and break things” dominated this industry for a while. It implied worrying less about the quality of construction or the process to refine and test your business idea and instead focusing on getting to market as quickly as possible. That idea works for some. But even Meta, who first coined this mantra, shifted away from it years ago (Mashable).
Unless you can afford to throw away your code, focus on the quality of the process and team, and reduce the number of features.
20% of startup founders now admit that they made a mistake in building too many features up front and not listening enough to users or studying the market enough (First Round - State of Startups 2017). By spending more time early on understanding your users needs and things they don’t need in the first iteration of your product, you can not only minimize the cost of an MVP, and have a much better sense for future phase features that can be implemented in what comes after the MVP.
There are ample cautionary tales of Minimum Viable Products that have gone awry due to poor construction, user research, and business planning. Here are a few from the career of one of our teammates: 3 Cautionary Tales
Cost factors in software
We generally know that square footage and local school ratings are going to affect the cost of a home.
In the same spirit, I want to share the factors and related questions you may want to ponder over that will affect the cost of your app:
How many key functions is your app trying to provide? Two easy ways to measure that scope:
- Number of features (try writing these in the format of “A user needs to be able to create a color palette").
- Number of user types (i.e. a customer vs an admin vs a manager)
- Number of forks in the process (i.e. when the customer can verify with a drivers license handy versus when they don’t)
Web, mobile, or both?
Generally web apps (those accessed via a web browser on a phone or laptop) are easier and quicker to build. Mobile apps might require 20% more time and monetary investment than comparable web apps.
Does your app utilize technologies that are complex on their own, such as voice recognition, live video chats, machine learning, or blockchain?
Are the users doing an entirely new activity on your app (such as reviewing their genetic makeup) or an activity that is generally familiar (shopping for clothes)? Based upon how familiar the activity is, you may need a user experience flow that is designed with the users’ diverse interests and behaviors in mind. You could, of course, choose to offer only rudimentary functions and allow your users to figure it out on their own. Understanding the WHY of your users is critical for successful application design.
Does your app need to look functional (because the concept is that novel) or more like a Ferrari (because it is in a competitive marketplace)?
Does your app need to integrate with existing apps? Some of those existing apps may be more involved to interact with.
Are you migrating existing users or products into the new app? That might necessitate other features or work to facilitate this transition.
What to do if cash-strapped?
Duct tape it with off-the-shelf tools
We’ve seen entrepreneurs succeed building their MVPs right away; they largely do so by building a lean version of their product using off-the-shelf technology. For example, one entrepreneur had built a version of their product into a spreadsheet and packaged it together with an online course builder called Teachable. Their first few customers paid for the service knowing that a more cohesive app was on its way.
|Duct Tape costs||~$850|
|Cost to build MVP||~$240,000|
|Revenue from first few customers||~$12,000|
Find a ‘low bono’ friend
Find a friend who is a software engineer and is willing to build you this MVP for a remarkably low rate (a rate so low that it might as well be considered pro-bono; hence “low bono”). They may help you in exchange for equity in the company.
There may be off-shore partners who would be able to work within your budget; we may even be able to recommend a few depending on the size of your budget.
We have seen some startup teams thrive with the MVP built by an off-shore partner. Later they were able to hire their own engineers to move the product forward. At the same time, we have also seen some teams hit the reset button thereafter.