I’ve been approached countless times by people telling me they have an app idea. I love this conversation because I get to try and convince them not to do it. The thing is, there is no such thing as an ‘app idea’. You can start a business and your main product can be an app. To pull this off, you’re going to need to have, and execute, thousands of ideas over the course of many years with the help of many people. If you don’t realize that, you shouldn’t build an app. If you do and still want to, I won’t be able to convince you not to.
The second misconception is that you can launch an app for a fixed cost. When you launch version 1 of your app, which should either be a testable prototype or an MVP, one of two things can happen:
1) Your value proposition is correct and users start using your app. In this case, you should be working to expand your user base as fast as possible by adding new features and improving infrastructure.
2) Your value proposition is incorrect and users don’t start using your app. In this case you should be working to tweak, iterate, and modify your value proposition as quickly as possible until you find product-market fit.
In either outcome, you will need to spend more money.
SF AppWorks Recognized as Top Mobile Development Company should only come after thoroughly understanding your competitive landscape and value proposition. I tell everyone with an app idea to write down the first ten features that will go into the MVP. Next, point out five competitors in the space and list the similarities and differences in their approach. 99 out of 100 times, I never hear from them again.
When to Build
If you have narrowed your features into the minimal requirements that prove your value proposition, while differentiating you from your core competition, you are ready to build your MVP. You have three options: Build it yourself, hire/recruit someone in-house to build it, hire a development shop or agency to build it. That’s probably the order you should do it in, too. But if you can’t develop it yourself and want to get the ball rolling while you look to build your internal team, you are ready to start talking to development shops like us. Before you do, think about your budget.
Native Or Hybrid App
What many people don't realize is that the two major players in the app market, Android and iOS, do not operate in the same fashion. What this means is that, as part of your decision-making process, you need to decide if you want to make your app a native app or if you want it to be a hybrid. A native app is one that is specifically designed and built for one of the operating systems, while a hybrid app is one that is built to run on both operating systems.
There are trade-offs to either route. If you opt for a native app, you will gain the full features of the operating system, but it will cost more since you’ll need to develop one app for each operating system. If you opt for a hybrid app, you can save cost by developing for both operating systems at the same time, but you sacrifice usability and stability by writing in a cross-platform code base that doesn’t take into account differences between each platform. Often, we recommend picking one platform and writing natively to ensure a natural user experience while honing in on the right set of features, then building on the other platform. But in cases where the app doesn’t leverage core hardware, you need apps on both platforms to validate your product, and the features are mostly the same for each platform, then hybrid becomes an attractive option.
Reasons People Don't Think Apps Should Cost As Much As They Do To Develop
When speaking with people about the true cost of developing an app, many are shocked to learn just how much goes into making a quality, workable app. When questioned about their shock, they offer several aspects to their reasoning: that software is easy to develop; that the app is really simple and light on features; that there are code free platforms that make it easy to develop an app. These people have probably never built an app before and don’t realize that an app is an extension of a business.
If the business exists, the app supports it’s value proposition in some way. If that’s the case, it will require an ongoing development effort to build and optimize features to grow the user base or increase revenue. If the business is new and the app is the main product, then it will take time to find the right set of features and UX to hit product market fit, and then you will need continued development to scale and to further enrich the core value proposition. Starting a business or growing an existing one through digital products is not simple, so why would building an app be?
Setting Your Development Budget
Success is about staying in the game as long as possible. If you have $100,000 to spend, it’s better to spend that over 10 months than over 3 months. 10 months gives you more time to raise more money, and learn more about your product-market fit.
How much do you need? Let’s crunch some numbers. I took some average salaries from Glassdoor, removed the outliers (Google pays its senior developers mid-six figures or more), then added monthly projections of the hourly rates of some of the low-end, mid-end, and high-end developer shops that we work with or compete against. Since we’re generalizing, I rounded the numbers.
A few more considerations when thinking about prices.
- The pros of in-house developers: Smoother communication. Gives you more acquirable assets down the road. With equity, you can align interest and ‘skin in the game’.
- Cons of inhouse developers: More expensive. Harder to retain. As they get more experienced, it becomes harder to resist cashing out at the big tech companies. Harder to scale up/down - if you decide to build an app to go along with your website, you need to hire new developers. Dev shops will let you swap out resource expertise as needed.
- Low, Mid, and High-end dev shops balance risk and cost. The risk of picking the low-price option is that they have lower margins. That means those companies will need to use less experienced developers and cut corners wherever possible, which could lead to incomplete or poorly built products. High-end shops have fewer risks, which you pay for in premium rates. Think of it as insurance. Mid-level shops, in theory, try to strike the right balance.
- No matter how you choose your developer team, choose carefully - it is very hard to swap developers once you start building. Some companies use this to their advantage, offering low initial engagements and then ramping up the costs once you are committed. Unless you’re getting a recommendation from someone who has direct working experience with your developer, ALWAYS ask to speak to one or two clients or references.
- An ideal app development team will likely need a developer focused on each platform (iOS, Android), a backend developer for data management, a quality assurance tester, a designer, a systems architect, and a project manager. If you go in-house, you’ll eventually need all of these. With a dev shop, they can provide the Support Team, usually for about 50% more than the developer cost.
For budgeting purposes, the middle road is the safe bet. Whether you go in-house and hire a few developers, or work with an agency, you can budget $45-60K per quarter for a simple complexity app, per platform, double for a medium complexity app, and 4X for a highly complex app.
I had to make a lot of generalizations and assumptions for this model. It’s really designed to be a starting point. No particular project situation is the same, so adjustments will need to be made as you plan your cycle product development cycle.
One last important piece in developing your budget for the app is what happens once you launch the app. There are ongoing support costs to maintain the app, as well as some development work as technology advances. So when you are developing your budget, it may make sense to have two budgets: one for the actual development of the app, and one for the ongoing support for the app.
Once you have your project budget and the development of the app is underway, be prepared to manage a growing wish list of features. At the start you may only want your app to do three things, but as the project progresses it is very easy for those three things to turn into six things, or more. As you discover new information, you’ll want to add new features. This can delay the launch and increase your costs. Keep your scope clearly in mind to help maintain your budget and timeline for launch. Build the minimal amount that you can to validate your concepts, and set quarterly milestones that ensure you launch the best version of what you can each quarter, rather than trudging endlessly towards the mirage of a perfect, feature complete app.
Set your product release schedule
For apps, we usually work in 3-month product roadmaps, with releases happening at the end of every two-week sprint. Limiting product cycles to three months gives you enough time to build a few heavy features, while quickly getting your product into the hands of users, which is the only kind of feedback that really matters.
During these 3 months, you and your dev team will work together to prioritize features and determine how much to build them out. The mantra here should be “make sure you’re building the right thing before you build it right”. In other words, move quickly, try a lot of things, don’t linger, and don’t aim for perfection.
Just Do It
Launching an app is a wild ride. You’re going to laugh and cry and feel trapped and feel excited, sometimes all in the same day. Understanding that this ride is going to take 5-7 years until you (hopefully) get your payout, and understanding that you will need an ongoing development budget, as well as a marketing budget, and a budget for yourself, can alleviate a lot of financial stress. While it may be hard, staying in the game is your competitive advantage - the difficult path will eventually knock out your competitors, if you can stay standing yourself. And know that where you end up will be a vastly different place than where you started. Have some fun, and let us know if we can come along for the ride.