This is exactly how much it costs to make an app

Answer: Whatever you’re building will cost at least 100% of your budget, likely more. Guaranteed.

Ok, that’s a bit tongue-in-cheek. But it’s true, even if it’s not what you wanted to hear. Digital things are like goldfish, they’ll always grow to fit their environment. In this case, the environment is the budget. Throughout my career as a product designer and developer, I’m frequently asked what it costs to make X. I understand that I’m being asked to help set a budget or give context for a work engagement, but here’s the thing… there’s a good chance I’ve worked on something similar. And guess what? I still have absolutely no idea what this thing will actually cost to produce. Nobody does!

Now before you write me off or send hate mail, I CAN tell you how much it will cost to find out what the big picture should look like. But before I share that, let’s look at why it’s so difficult to define the cost for an app up front. (I’m using the word “app” to represent any digital product, complex website, or tool.)

Why it’s so hard to price an app

Humans aren’t very good at sharing our ideas verbally

When I’m approached for pricing, the conversation usually starts by someone describing an idea they have. This person typically wants to know exactly how much it will cost to make their idea real. It’s a fair question, but here’s the thing about ideas, they’re really hard to describe. Anything someone tells me about their idea is only a shadow of what’s in their head. Plus, after our conversation, the thing I see in my head is likely pretty inaccurate. Think of this process like the kid’s game of telephone; the start and end are pretty different.

Problem #1: I’m estimating from an inaccurate starting point. This also means I can’t imagine all the pitfalls, features, technology structures, or variations that need to exist. Therefore in an attempt to protect myself, I’m going to seriously inflate the estimate.

We lack a shared definition of “real”

I don’t know how to estimate the cost of making something “real”. Does that mean that you can see it? Is there interaction required? How will we know when it’s real? Typically, I believe, making it “real” is the expectation of the app being “done”. It’s something that people can just pick up and use focused around the old if we build it they will come adage. Sadly that’s an ill-defined, moving target.

Problem #2 is that apps are like a living organism. Learnings and time lead to an evolution that makes a definition of done extremely difficult to achieve. Not knowing when it’s done scares vendors, opens the door for a very poor working relationship, and, you guessed it, confuses the budget.

The customer/user is an enigma

In my experience, most budget conversations are triggered by a deeper desire to understand ROI. In other words, is this worth the effort? There may be plenty of evidence that “people want” the app to exist, but that doesn’t convert to really understanding user needs. Unfortunately, people are fickle and lazy. Everyone might say they’re very interested, but that rarely translates into actual use.

Problem #3 is that it’s difficult to predict value at the idea stage. Therefor matching price to value doesn’t reflect reality at this stage. In other words, it will always seem expensive.

Moving forward from a difficult question

So where do we go from here? Obviously budgets, seeking investment, doing projections and product roadmapping are part of business. It’s not fair to simply tell everyone to stop asking what it will cost. Instead, it’s time to change the approach. The idea of an iterative software approach has been gaining traction over the last several years. Things like Agile Development,The Lean Startup mentality, and Design Thinking are great tools but the average business is unsure of how to apply them to the process of “making something real.”

At this point, I suggest breaking down a project into multiple smaller phases that CAN be easily estimated. Each phase builds upon the knowledge gained from previous phases AND allows for course correction before the entire budget has been blown.

Phase One: Prototype and Test

Before making an app “real” you should make it very “fake” and use that to learn something. In the industry we call these fake versions “prototypes.” They’re usually just enough to start getting real feedback from your audience. In Phase One you’re making a small time/money investment in understanding viability and desirability with real users to build confidence in the next steps.

I personally love utilizing Google Design Sprints as a method for completing Phase One. Design Sprints are SHORT, typically 5 day, workshops designed to produce and test prototypes for a concept. As a Design Sprint Master (facilitator), I can tell you EXACTLY what it will cost to run a sprint as well as the type of learnings available at the end. Now we’re getting somewhere and the budget at this stage can be very concrete.

Phase Two: Prototype and Test Again (maybe)

Depending on the concept/problem being solved, the prototype tested at the end of a Design Sprint might not be comprehensive enough to fully test features. It may not contain enough screens, interactions, make too many assumptions, or there could be missing flows (like a sign-up process). In these cases it’s wise to build and test a second prototype (don’t forget to incorporate the learnings from testing in Phase One).

A Phase Two prototype can be done in-house if you have the skillset, by a freelancer, or a small team. The catch at this point is to keep building something fake. Many teams get stuck worrying about the technology or scalability. Avoid this, remember it's still fake. Instead, share the prototype and findings from Phase One and detail exactly how you would like to expand upon it. This process should again yield an accurate estimate of time and cost for this phase.

Phase Three: The MVP (but not the most valuable kind)

A M inimum V iable P roduct is the next step toward learning and validating an app. It also starts making things “real” with actual code, potentially a database, and working interactions. A MVP allows real users to engage with your app but only through a small subset of the final feature list. Similar to a prototype, an MVP could end up being throw away code. It may not be scalable or even built with the final technology (perhaps a native mobile app could be built as a web app first). You should expect that behind the scenes features won’t exist (maybe you’ll have to manually generate user credentials, process credit cards, or reset the server), but an MVP allows “beta” users to actually USE your app for the first time.

To get an accurate price estimate for an MVP, simply show the team/vendor the prototype from Phase Two and be honest about its purpose (If you have 4 beta customers don’t say it has to work for thousands of people). Also be very realistic about which features HAVE TO EXIST, usually many fewer than you think, at this stage.

Phase Four: Making it REAL (really, really)

Congratulations! At this point you have a fantastic idea of your app’s viability, desirability, and feasibility. You may even have a few paying customers. All that’s left is to remove the duct tape and build from a solid foundation with an eye toward the future. Armed with your prototypes and MVP, you can finally select a vendor partner to get an extremely accurate estimate. Instead of asking what the idea will cost, show potential vendors what’s been built to this point, and ask “What will THIS cost?” Since everyone has a great idea of what needs to be done, you can be comfortable with the accuracy of estimates and even technology recommendations. Often you will gain a true “partner” who’s equipped to care about your success instead of simply fulfilling a statement of work.

A word on investment…

It can be extremely tempting to ask for investment (monetary or organizationally) to cover the ENTIRE process of building a digital object/product/app. Please avoid this temptation. Instead ask for small investments to learn so you can continuously present value back to the investors. Small purpose driven investments, also mean you’re not stuck with too few resources to accomplish your goal and allow you to pivot if a better path presents itself.

Originally published on Medium Jan 13, 2018 Bryce Howitson

By day, I’m a product strategist consulting on all things digital and a Design Sprint Master. By night I’m a Google Expert, a startup mentor and writing a book about getting started in UX. Follow me on Twitter @howitson.