Bill and I were only ten minutes into our meeting when the question came up.
It always comes up, but today it was a little quick.
“So…how much does it cost to create an app?” he asked.
I smiled. “It depends on how sophisticated it is, but a good rule of thumb is the first version of an app with any substance will cost between $300,000 and $750,000.
“Then there’s supporting your customers and adding new features as you get feedback. Over the lifetime of the app your total investment will be between $750,000 and $5 million or more, depending on how aggressive you are about releasing new versions.”
He paled a bit. “But I just got an e-mail from an offshore company that said they can build me an app for $25,000!”
Your Options
There are a variety of options for getting an app built, including finding a technical co-founder who will spend all of his or her waking hours coding the app for nothing but some money to pay their bills and an equity stake. This will certainly save you a huge amount of up-front cash, and it’s a great route if you find the right match.
I’ll assume for a moment that you’re not in that situation, and I’ll also assume you don’t have the technical know-how to go out and hire your own software development team, assuming you could even find talented software engineers. You need to hire a software development company to get your app built.
You can get a simplistic app built for $25,000, by using an inexpensive freelancer or a bargain-priced offshore company. However, there are a lot of pitfalls when building mobile apps, and it takes an experienced team to do it right. Most likely it won’t be $25,000 by the time you actually get the features you want, to the level of quality you need.
In the rest of this post I’ll talk about what drives project costs and give you some tips on how to keep them as low as possible. Feel free to follow along by downloading our Software Development Estimate Template.
What Drives Cost?
In any project there are only four variables:
- Scope
- Time
- Cost
- Quality
These are oftentimes represented as a triangle, since scope, time, and cost each affect the other, shown like this:
Some examples of how these impact each other:
- If you increase scope – the number and complexity of features – you’ll increase time and cost.
- If you have a hard deadline, you can increase the cost – typically by increasing the number of team members or the hours they are working on the project – or you can reduce scope.
- You’ve come up with the minimum required scope for version 1.0 but you don’t have a hard deadline. You can go more slowly and get it built for a lower cost.
In each of these examples, I assume that quality is fixed. Your app needs to meet a minimum standard in order for people to use it.
It can’t crash every 5 minutes. It can’t be unusably slow. And its features have to actually work.
Your First Job
Any time I have a conversation with someone about their new app idea, they typically leave with a homework assignment: figure out what the minimum viable product (MVP) looks like.
A couple of years ago we were hired to overhaul the software technology for a company that wanted to move their server software to a cloud-based software as a service (SaaS) model.
They also wanted to move their mobile app from a legacy Windows Mobile platform to Android and iOS. They wanted to introduce the new product at a trade show that was six months away.
The only problem was the current version of their product took more than five years to build.
We rolled up our sleeves and built a new mobile app and cloud-hosted server app from scratch, and delivered a month ahead of schedule, for a total cost of about $160,000.
How?
We asked this question over and over:
“Is this feature absolutely required for a customer to start using the product?”
If the answer was “no,” then onto the Version 1.x list it went. Only if the answer was “yes” did it make it onto the Version 1.0 list.
By focusing tightly on the concept of MVP-a product that has only the most crucial core features, and no more – we were able to defer most of what was in the existing product and build only what was critical.
Did it mean every current customer could upgrade to the new product right away? No, but it allowed our client to show off their new solution to trade show attendees who hadn’t seen the existing product, and future releases evolved to include the features that existing customers were using.
An MVP is a product that some customers can start using, but initially it won’t satisfy the needs of every potential customer.
Interestingly, we still haven’t built all of the features that were in the first product. Our client’s customers simply haven’t asked for them.
Do this exercise with your app concept, and you’ll not only get your first version out the door more quickly, you’ll do it much less expensively.
Tips to Keep Costs Low
Here are some tips to help you keep your cost as low as possible, especially for your MVP.
Remember the goal with the MVP is to get something into customers’ hands as quickly as possible, so you can not only validate your concept and ensure it’s marketable, but to also get feedback to help drive further development based on what people want.
Limit Scope
I already talked about this in Your First Job, above, but it bears repeating. Keep your scope as small as possible.
Every feature you add will increase cost, and not all features are equal. Some will cost more to develop than others. The best approach is to keep the list of features short to speed development.
Don’t Get Fancy Out of the Gate
In addition to limiting the number of features, keeping each of them as simple as possible will also save you time and money.
I suggest to clients they not only think about a minimum viable product, but think of the minimum viable feature for everything on their list.
Ask this question about each:
“What’s the simplest possible way this feature could work and still deliver value to our customers?”
Let me walk through an example.
Let’s say you’re including a messaging feature in your app, and you want to support emoticons–those smiley faces you see when sending text messages on your phone.
Below is your outline of the behavior you want:
Version A:
- I can type a text emoticon – for example :) – and the app will change it to a graphical emoticon when the message is sent.
- The app will recognize any of the following 22 character-based emoticons and convert them to a graphical emoticon:
- :)
- :(
- :b
- (etc…)
- I can pick from a list of graphical emoticons when typing a message
- I can add my own emoticons by uploading a graphical image
- I can download new emoticons from the Internet
Let’s think a bit about what’s needed:
- Code to recognize all of those combinations of text.
- A graphical designer to create the emoticons, or the team needs to research whether there’s some sort of library available of emoticons we can use.
- Handle if the images uploaded by the user are the wrong size, wrong type, too big, too small, etc.
- Code to allow downloading emoticons from the Internet in the app.
- Testing of all of the various combinations of text and graphical emoticons.
Here’s an alternative version:
Version B:
- I can type :) and the app will replace the two characters with the following emoticon when the message is sent:
- No other text or graphical emoticons will be supported in version 1.0.
Which do you think will be less expensive?
My prediction is Version B will be one tenth the cost. And the feature is still usable and delivers value.
Is it the Rolls Royce version? No, but it’s also highly unlikely customers will stop using your app if your first version doesn’t include all of the aspects of the Version A feature.
Don’t under-estimate the potential impact of “fanciness” at the individual feature level.
Go Slowly
Sometimes there is a time crunch. You need to have an MVP in eight weeks. Other times limiting the cash outlay is the most important factor, and you can wait a few months.
To save money you can slow things down a bit. You can consider using a smaller team and/or a team working less than full time.
Even a small team can get a lot done. In the example I talked about earlier, where we re-built the existing product in only five months, the budget was extremely limited. We put together a lean team that was structured like this:
- Project Lead (“Product Owner”): 12 hours/week
- Project Manager (“ScrumMaster”): 8 hours/week
- Software Engineer: 16 hours/week
- Software Engineer: 16 hours/week
- Quality Assurance Engineer: 8 hours/week
This approach saved the client a ton of money but still delivered on their business goals. They were absolutely delighted–and a little shocked–that we could accomplish so much with such a small team.
Limit Visual Design
There is a sliding scale when it comes to the look of your app’s user interface (UI). You can release something that has a very basic look and feel, but does something really valuable or interesting, and people will use it.
Have you ever seen version 1.0 of Facebook?
Not a lot of high-end visual design going on there.
If you spend a bunch of money to dress up the UI – especially for your MVP – and it turns out no one wants your app, you’ve thrown that money down the drain.
Once you prove your concept, you can add some “spit and polish” in future releases.
Some apps require a high degree of polished visual design out of the gate, for example if there are established competitors you’re up against and customers complain about its look and feel. In this case you probably want to spend some money on design, but limiting scope will help limit the related visual design cost.
Just to put things into perspective, a full-blown visual design process for an app can run anywhere from $20,000 to $100,000 or more, depending upon the size and sophistication of the app and whether there is a companion web site.
The good news is once you get some traction and a proven concept, it’s absolutely possible to give your app a face-lift without having to re-build it. Adding a new “skin” on top of an existing app is much easier than making all of the features work at the beginning of your project.
Summary
There is a minimum amount of money you’ll need to spend to build an app of any level of sophistication, but there are ways you can keep software development costs as low as possible.
Here are three key cost-saving tips:
- Ruthlessly cut features to create an MVP.
- Keep every feature as simple as possible.
- Adjust team size based on your time requirements.
Producing anything of value is going to require an investment, but these tips will help you keep the price tag down until you get some traction with your new product.
