How Much Does It Cost To Build An App?

How much does it cost to build an app¹?

The shortest and best answer I can give is YOU DECIDE!

Wait, What?!

That’s right, you decide. There certainly are some general minimums you should consider as you establish your budget, and I have provided those here, but you get to decide how much you want to spend on developing custom software. Please read the entire post to best understand what I mean. If you are just trying to get a rough idea (that would be me the first time the thought came to my head), read the next four lines and bounce. Don’t worry, you won't hurt my feelings. Plus, you can always come back to learn more later.

Here are some common prices ranges:

Research, Prototype and Validate: $50,000 - $150,000+
Consumer-facing Web or Mobile Application (App): $150,000 - $350,000+
Enterprise Software Product: $250,000 - $1,000,000+

How do I know what it costs to build an app?

The ranges I note here have been aggregated from over 100 custom software builds completed by Airship. Not every custom software project will fit into these ranges, but they can give you a good idea of what it will take as you consider a custom software build.

I have been leading the Opportunity Explorers team here at Airship for over six years. As Opportunity Explorers, we are typically the first people to interact with our prospective clients. I have been asked hundreds of times, “how much does it cost to build an app”? For years I have given some version of “it depends” as the response and then walked the individual through the process of discovery, research, design, and delivery.

With the publishing of this blog post, I am turning over a new leaf! I am now going to respond with “YOU DECIDE.” I will still help our prospective clients understand the process, but now ensure that they do it from a new vantage point. My goal will be to empower them(maybe you?) to appropriately wield the power they have to guide the course (and the cost) of their custom software application project.

Assumptions

Let’s go over a few assumptions. I studied Mechanical Engineering in college and worked as an engineer and operations manager for several years. When working on a complex problem impacted by several factors, I was trained to list my assumptions. That practice helped me identify the particular circumstances and which solution path was applicable. Let’s apply the same method here to determine if my advice or explanation applies to you.

If you are reading this blog post, I am assuming one or more of the following about you or your strategy:

1. You are considering building a new software application from scratch as opposed to adding features to a software product that already exists.
2. You are not very familiar with the process of building software. You may be thinking that a verbal or written description of features should be sufficient to offer a confident estimate of the costs.
3. Your primary concern, for now, is the initial investment to design and build the custom application, not the long-term investment for maintenance and ongoing enhancements.
4. You are a start-up founder, and your product will be software or your business will be tech-enabled.
5. You are a leader in a non-technology business or non-profit, and you believe that a custom software solution could be transformative for your interactions with customers, clients, vendors, internal teams, or organizational stakeholders of any kind.
6. You are planning to hire an experienced and professional firm to build your app instead of hiring a development team².

How to set a budget for custom software development?

Three steps:

1. Determine the value of the software product.
   1. Consider and estimate the benefit you or your organization will receive over time. It could be additional revenue, reduced expenses, or just an exceptional customer/client/user experience that can be delivered in no other way.
   2. Establish an acceptable return on investment (ROI). You must have other ways you can spend money to advance your organizational objectives, right? What rate of return is required to make this an attractive project over those other potential initiatives?
   3. After determining the rate of return, then, you can calculate how much you would need to spend in order to have the custom software project move to the top of your priority list. This calculated number is your budget.
   4. Value to your organization = the benefit you receive - the cost of the project
   5. Let’s say that you expect at least a 20% return on your investment, and you expect that completing this custom software project will bring net additional revenues of $100,000 per year on an ongoing basis. In that case $100k/20% = $500,000. Therefore, $500k could be considered a reasonable budget for the project.
2. Understand what type of software product you intend to create
   
   1. To do that, just check out the guidance I provide here in this blog post and determine which category you think you best fit.
      1. Research, Prototype and Validate: $50,000 - $150,000+
      2. Consumer-facing Web or Mobile Application (App): $150,000 - $350,000+
      3. Enterprise software product: $250,000 - $1,000,000+

             2. Or just review our pricing page, where you can find more detailed guidance.

      3. Combine steps 1 and 2 to select a budget that fits the type of software application you want                       to create and the value you expect to generate. When these two match up, you can have                             greater confidence that your budget will be appropriate and sufficient.

You decide your budget - Doing so saves you money!

Declaring your budget at the onset of the process can be the most effective thing you can do to get the most out of your total spend when starting a custom software development project. You have probably heard the old adage “time is money.” There may be no place that this is more true than working with a professional services agency. Most agencies charge per unit of time. Some by the hour, some by the week or month. In any case, you end up paying for the time spent planning, designing, and developing your custom software product.

In order to get the most for your money, you want to partner with your selected agency to work most efficiently through each stage of the process. When you are building your strategy and designing the app, you want to do that with your budget in mind. One of the biggest time wasters, and thereby money wasters, can be planning for and designing features that you either can’t afford, don’t want to pay for, or your intended users will never use. Money spent considering, or even worse, building features that should not be in the first iteration of the software due to budgetary constraints is a real problem. Many times we have experienced a client being completely insistent on a certain feature until realizing the cost of creating it. Having an appropriate budget as a guide and visible constraint throughout the process will keep the entire project team focused on what matters and ensure you get the best bang for your buck.

You decide your objectives - Sharing them saves you money!

Most of the individuals I interact with that are interested in creating a new software application already have features in mind. I think this is wonderful! These individuals have already thought through the benefits they want their users to enjoy. They have started building a list of what the users will need to do and how they will need to do it in order to access those planned benefits. It’s very exciting!

As I start to encourage our prospective clients to unpack their project needs, it is quite often that they pause to explain how they are not the experts in building custom software, that is why they came to us in the first place. They go on to explain that they want us to use our diverse experiences across many different projects and industries to help bring fresh ideas into how they serve their intended users. I would say that this happens 8 out of 10 times I interview a prospective client. I also think this is wonderful. The client is coming to a professional firm like Airship and is rightfully seeking advice. Oftentimes, what they are saying is that they want us to use our experience to create the desired feature in the most efficient way possible. We should and certainly will do just that. In order to unlock the full potential of our team’s experiences, I strongly encourage people to tell us why they desire the features they describe.

If our software product team can understand why a client desires a particular feature, then our creative energy is no longer constrained to the limited scope of the stated feature. We are now equipped to adapt the feature, expand it, or eliminate it together to deliver on our client's why as opposed to their what. Our CEO, Trent Kocurek, prefers the word “objectives.” He implores us to understand our client's objectives. An objective is more like a goal or a desired outcome, whereas a feature is more like a singular option or path that can be used to reach that goal.

Share your goals or objectives with your software development project team. Encourage them (maybe us 😉?) to be creative in how the objectives are achieved. Work hand in hand with your product team to evaluate feature options, perform research and build a minimum version to validate assumptions. Software developers are often called software engineers because they engineer the optimum software solution. I am currently reading “Trillion Dollar Coach” by Schmidt, Rosenberg, and Eagle³. The book is intended to be a leadership playbook that follows the career of one of Silicon Valley’s most prominent advisors and consultants, Bill Campbell. Bill was an executive leader at Apple, Intuit, and GO. He was also a prominent advisor to a great number of leaders at Google. In chapter 2, the authors described how Bill believed that there was “nothing more important than an empowered engineer.” They went on to say that Bill encouraged his software product owners to tell the product teams and engineers the problem the intended user has and give them context on who the intended user is and let the product team figure out the features.

Sharing your objectives is one of the best things you can do to equip your product team (whether employees or a professional firm) to deliver the optimum product while simultaneously eliminating waste and saving you money. Decide what your objectives are, and then share them!

You decide on the number of features and the level of those features

The number of features decision
Once the product team⁴ has determined some best-fit features that can meet your objectives, you will get to decide how many of them will get released with the first version. We encourage clients to prioritize the features based on what they believe will be most impactful. This prioritization can come from the product owner and his or her knowledge of the intended users. Alternatively, the research could be employed to get feedback, and the results of the research can be evaluated to prioritize potential features. In any case, the choice is yours. Choosing to prioritize the right features can reduce the cost of the initial build.

The level of each feature decision
You decide on what I describe as the “level” of each feature.

What do I mean by “level”?:

• The polish or aesthetic appeal of the user interface (UI) design
• The nuance of micro-interactions⁵
• The full extent to which the feature serves its purpose

You can think about the level of each feature as a skateboard, car, or something in between. Henrik Kniberg used the following imagery and analogies when describing lean and agile software development practices (see Figure 1). In some ways, each individual feature can be a skateboard or a car. You will have the opportunity to determine the level of each feature, and that decision will impact the cost of the project. The more often you choose a skateboard, a scooter, or a bicycle over a car for your first version of a particular feature, the lower the project price. An added bonus is that choosing a lower level for your features can give you the benefit of actual user feedback and validation before increasing the level (and cost) of that feature over time. Custom software can and should be ever-evolving. Actively looking for ways to choose a lower level from the beginning can be one of the cheapest ways to learn and accordingly direct the future course of your digital product. Kniberg’s point was to choose the skateboard when you can so that by the time you get to the car, you will know just what type of car to build. In any case, the choice is yours. You decide the level of each feature and thereby decide on one of the more critical components of the full project price.

Figure 1 - Credit Henrik Kniberg

As part of deciding the number of features to include in the first release, you have already prioritized your feature set. You can use this same priority list to help you determine the appropriate level of each feature. You may want to consider a higher level for features that are the most important and reduce the level for features that are lower on the list.

If this seems like a daunting task, don't worry it's not as complicated as it may seem. By simply using the skateboard to car analogy, you can assign relative weight to individual features. That relative level indicator, combined with the budget you already presented, will help your software product team (that's us) make effective choices when engineering and subsequently creating your software product.

Custom software that is intended to be used by consumers or the general public may need comparatively greater polish or aesthetic appeal in the first version in order to attract enough users for feedback and learning. Alternatively, applications that are intended for use inside an organization may not need as much visual appeal because of the somewhat captive audience. Take the use case and intended audience into consideration when deciding on the level of each feature, whether planning the first release or the 20th.

You don’t have to decide alone. Airship can help.

Making high-quality decisions on a consistent basis is really tough. That can especially be true when you don’t have much data, and you have little to no experience in developing custom software. This is precisely why we created the software product lifecycle here at Airship (Figure 2). We want to use our experience to be your guide.

^{Figure 2 - The Airship Process}

^{At Airship we use our Explore phase to discuss your problem or opportunity and help you to determine if custom software could be a viable solution. Our initial consultation is free, and we encourage you to reach out for a conversation. In the Discover phase, we guide you through a systematic methodology that has been refined over the course of over 100 projects to help identify objectives and risks, then choose features. In Delivery, we employ research to tease out insights. We then use iterative design and development to solicit feedback with bi-weekly progress demonstrations. This iterative approach gives you the opportunity as the product owner to confirm progress and course correct as needed. Once the software product has reached the desired state, we will Release it to your intended users. We can then start reviewing some of the most valuable feedback and data from live users. That feedback and data can inform the next cycle of research, design, and development.}

Your next step

<sup>If you have made it this far, my hope is that you feel encouraged and empowered. I hope that the process of choosing to move forward with a custom software development project has been demystified and you are now more confident about all the authority and tools you will have at your disposal to make excellent choices regarding the total cost of this important initiative.

Your next step is to click the link below and book a meeting with me so that we can connect for a consultation. You have my assurances that I will do my best to act as your guide through the process I just described.</sup>

^{My contact information:
Luke Richardson - VP & Opportunity Explorer
Book a meeting with me here: https://teamairship.com/meet-with-luke-richardson/}

Footnotes and references:

1. App is an abbreviation for “application.” Mirriam-Webster’s dictionary defines "application" as: a program that performs a particular task or set of tasks. "Software" is defined as: something used or associated with and usually contrasted with hardware, such as programs for a computer. The abbreviation "app" is especially and most commonly used in reference to a software application designed for a mobile device such as a smartphone. For the purposes of this blog post; I will be using the terms, app, software, software application, and software product interchangeably.
2. If you are wondering if hiring a software development team is “cheaper,” the answer could be yes or no. Be sure you are considering the full team you may need. That team could include researchers, designers(UX and UI), developers(front end & back end), product owners, project managers, quality assurance, and more. Also, give some consideration to the level of risk you desire to take on with full-time employees and what level of backup or redundancy would be needed. I can’t cover the full extent of what to consider here but would love to talk through it with you as needed. Please see my contact information here in the post and reach out.
3. Eric Schmidt, Jonathan Rosenberg, and Alan Eagle. Trillion Dollar Coach: A leadership playbook of Silicon Valley’s Bill Campbell. HarperCollins. 2019
4. The product team includes you as the product owner who makes the decisions as described in this post. Additionally, the software product team will likely include many of the following roles or capabilities. Some people may fill multiple roles or multiple people may be needed for a single role.
1. Researcher
2. User Experience (UX) Designer
3. User Interface (UI) Designer
4. Project Manager
5. Developer
6. Quality Assurance
7. Business Annalist (BA)
5. The Nielsen Norman Group definition: Microinteractions are trigger-feedback pairs in which (1) the trigger can be a user action or an alteration in the system’s state; (2) the feedback is a narrowly targeted response to the trigger and is communicated through small, highly contextual (usually visual) changes in the user interface. Examples of micro-interactions are scrollbars and swipe animations.
6. Image credit to Henrik Kniberg from his 2016 blog: https://blog.crisp.se/2016/01/25/henrikkniberg/making-sense-of-mvp