How Much Does it Cost to Develop an App?

I feel that $10,000 is a fair number to use for the cost of a well-built app. Sure, it is possible to pay less than that (and much more!), but in general, as that price goes down, so will the quality of the app. To quote Davide Di Cillo, an iPhone app developer and the founder of GetAppsDone.com:



For some background on why that number is in some ways a conservative estimate, note that many apps will take between four and eight weeks to build, with the average being six weeks. With a full-time developer (40 hours per week) and a part-time designer (20 hours per week), the average man-hours per week is around 60. Six weeks multiplied by 60 hours per week equals 360 hours. Solid designers and developers will charge around $100 per hour, with top talent peaking at around $150 per hour and lower-end U.S.-based contractors charging around $65 per hour. Using the $100-per-hour rate yields a total of $36,000 (360 hours × $100 per hour). That number can quickly fluctuate: if your app took four weeks to build (240 hours) and the average was instead $75 per hour, the total would be $18,000 (240 hours × $75 per hour).

Note: For games, the number of total hours is much higher, and ranges between 700 and 2,000 hours. This equates to three to six months of work, depending on the number of developers working on the game simultaneously.

It may astound you to know that depending on complexity, the cost of developing an app can range from less than $5,000 to more than $100,000. That lower boundary typically involves working with offshore or independent developers, whereas the higher number is from hiring professional companies or agencies. Looking at the median cost from TheyMakeApps.com (see the image below), a resource for finding app developers, you can see that development cost lies within the $10,000 to $15,000 range. Contractors have also requested that TheyMakeApps.com add a $50,000+ category to assign to their listing.




One last note about these costs: on the lower end, they largely assume that you are acting as the product manager for your app, performing the roles described earlier. This implies that your “services” are free. To perform a more rigorous cost analysis, you might consider including your hours in these estimates. Assign yourself an hourly rate—perhaps what you could make if you were consulting, based on what you make at your job, or by actually paying yourself some sort of salary—and multiply that by the number of hours you plan to spend on your app per week. Add that to the previous numbers to get another perspective on costs.

Reconciling costs

The reality of the situation is that you are in a hot market in which people with the skills to build apps are scarce resources. You’ll find that the best designers and developers won’t haggle with cost estimates or their rates because others will gladly pay them.

To reconcile these costs, start with the quantification of your app. You should understand the larger purpose of this effort (e.g., it’s the start of a long-term investment in the mobile space) and, if you are pursuing a paid app, have some sense of what the financial returns should be.

Although I’ll show you some practical ways to lower costs, you need to be able to reconcile them with the motivation behind your app. Mentally you must be “all in” with your app, equally committed to it and prepared to lose anything you’ve invested. That’s a telling yet truthful statement about the nature of the App Store.

Note: Remember that if you continue to update your app once it is launched, each update will also come with a cost. Depending on what the updates include, they typically will equate to a fraction of what it costs to build the entire app. Not accounting for them, however, can give you a false sense of out-of-pocket costs.

Ways to save

Ensuring that your product assets (e.g., initial research and wireframes) are as detailed as possible is a smart way to reduce your costs. If you have little or no experience building software, some of these items will not be more fully completed until your team is in place. Even before then, however, do your best to think through the biggest challenges of your app. Bringing more information to your potential resources will help them better estimate costs and build your app more efficiently. Both of these will impact the bottom line of what it costs to build your app.

Second, try to keep the first version of your app as simple as possible. That means scaling the app back to its key features, choosing what has proven to be most important to your customers. This approach not only is helpful from a cost perspective, but also is a strategic decision for your app. Many apps try to do many things at once, and as a result, they do nothing well. Thus, by focusing your first release in this way, you’ll reduce the risk of overinvestment while also developing a better app.

The experience, quality, and location of those you contract can drastically impact costs, but not necessarily the way you’d think. For example, working with offshore or less experienced resources (such as students or recent graduates) can put your app cost more in the range of several thousand dollars. Yet, this usually can be accomplished successfully only by people who know how to collaborate with these types of designers and developers to achieve the results they want. Those who are less seasoned or have no experience in this area often choose the cheaper option, only to spend thousands of dollars with an unsatisfactory outcome, or worse, with nothing to show for it. The investment, in this case, becomes considerably higher than initially agreeing to a more costly estimate or hourly rate from more experienced or proven resources.

There are additional challenges with offshore or overseas resources, including language barriers and adjusting for time zone differences. Again, it’s possible to overcome these problems, but few have gotten the formula just right; the benefits are numerous to those who have.

A lesser-known way to reduce the cost of building your app is to find developers who are willing to reuse code from their other apps or client projects. The reason is that the actual development usually represents the largest portion of the cost. You might even consider working with a developer who has developed an app that is similar to your idea.

The caution for this approach is that you’ll need to ensure that you have the full rights to these assets—through a written agreement—in case you sever your relationship with the developer or your app is acquired. In the first case, you wouldn’t want the developer to keep the code if he is no longer involved in the app. In the second case, you wouldn’t want the developer to claim that your app couldn’t be sold or that a portion of the proceeds were owed to him.

On this point, I want to conclude this section by addressing the use of partnerships and revenue sharing (referred to collectively as “partnerships”) as a way to lower costs. It’s possible that instead of paying for help, you might convince people to lend their skills or assets for free in exchange for partial ownership of your app, a share of the app’s proceeds, or recognition (if you have a free app).

In most cases, I find that one or more parties in partnerships become disillusioned by the perception that another party is not as committed or is not doing as much work as other members. This causes frustration, distrust, and often a dissolving of the partnership before the app even makes it to the App Store.

One remedy to this situation, which does not make a partnership foolproof, is to have a written agreement that stipulates how the equity is divided beforehand. This solution also has its problems, because it may not be clear what each effort is worth. For instance, since the main value you might bring to your team is your idea and your understanding of your app’s landscape, doing “less work” in terms of building your app shouldn’t necessarily imply that your share of the app should be lower than others’.

Another major issue with partnerships is that disappointment and frustration can occur if the app does not immediately meet expectations when launched into the App Store. Part of the underpinnings of a partnership is the promise of the app. If it appears to have no promise through its download count or sales numbers, your partners may be unwilling to continue to invest their time in it. This can leave you in an unsettling predicament.

If you are absolutely determined to build your app using a partnership, at least do so with people you’ve worked with in the past or have known for some time. And still be sure to put the terms of your partnership in a written, signed document. My overall recommendation is that if your idea is worth pursuing, consider some of the options to reduce your costs, but be willing to invest money in it. Doing so will simplify legal paperwork, and ultimately will allow you to drive and own the direction of your app.