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.
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+
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.
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:
Three steps:
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.
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.
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 Eagle3. 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!
The number of features decision
Once the product team4 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”?:
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.
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.
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.
My contact information:
Luke Richardson - VP & Opportunity Explorer
Book a meeting with me here: https://teamairship.com/meet-with-luke-richardson/
Footnotes and references: