What should an MVP budget be?

“How much should we spend to build a product or MVP?!” Before we get into all that, let me first describe how we define an MVP (a POC and a Feature).

MVP: is a standalone product or application that completes one or more functions in a feature-complete way. This MVP can be delivered to a closed/limited group, or publicly to all users. The main distinguishing factor is ‘viable.’

POC: is an internally delivered application or clickable prototype, intended to prove the feasibility and functionality of a collection of features.

Feature: is one element or function of a larger POC or MVP. For example, adding 2-factor authentication to a login — 2FA is a feature.

For this conversation, we’re going to be focused on the MVP. It is good to know however, that POC will likely be a phase or milestone when building your MVP. For further painting the picture of this imaginary MVP, let’s say it is a desktop application, with end users, financial interactions, and some social functionality between users.

Questions we get . . . a lot:

1. On average, how much does it cost to build a product like ours?
2. We need to launch in 2 months, is that possible?!
3. We have $X, is that enough to build our product?
4. We already know exactly what it is, can we skip the Discovery phase?

In an effort to help you answer these questions, I’ll talk about our process and philosophy for healthy product development. First, and if you can, you should establish some general budget thresholds for building your MVP. It’s ok if they need to shift somewhat, but a baseline and degree permissible shift is important. If you cannot (or don’t need to because you’re already very well funded), there will be a first phase that sheds more light on what the MVP budget will likely need. This first phase is called Discovery (also called Scoping). This process is always aided by having a brand strategy, executive summary, regular participation from the principle stakeholders, etc. When we work on completely new products, without having a working brand strategy on hand, we’ll usually apply that brand-specific discovery as well in that Discovery Phase. There is so much importance in the identity, value proposition, and true north.

Discovery sets out to learn everything necessary about your product and ultimately will help to narrow in on building said MVP. In this Discovery, we examine business opportunities, user profiles, key value delivery, market, desired features, etc. We distill all this learning into: user goals, business requirements, technical requirements, timelines, skills & resources (team members) and budgets. Having produced clarity on the aspirations (goals) and requirements to deliver on them, we can produce a healthy and more accurate budget and timeline for building that MVP. This is if we didn’t already have an established budget at the genesis of the project. When we have a budget at the onset of the project, we’ll use it to aim that Discovery towards an MVP within our general budget, +/- an acceptable variance.

Let’s look at one scary outcome of a Discovery phase with no budget:

“Whooaaaaaa, we cannot be spending that much on this MVP.” Great, now that we know it will take “X” to build the MVP we originally envisioned, what can we remove or dial back to make a truly minimum MVP? Once we perform these retroactive exercises on the project SOW, we’re ready to move forward building our MVP.

We think that on average close to $500,000 is a best-budget for an MVP. How did we get to this number? Well for one thing, we’ve been building MVPs for start-ups since 2011. So, we have years of data supporting our logic. We apply that same data to produce a healthy timeline. If we’re building (after Discovery) for more than 4–6 months, we’re likely missing some opportunity that the start-up is looking to take. That opportunity might be going to market and tapping into a honey pot of unaddressed users. Or simply being able to show investors a responsibly launched V.1. That might be getting an MVP to new investors. Just like you, we want to ship as fast as reasonably possible!

One important consideration many startups fail to recognize, no matter how adamantly we communicate it from the beginning… is who on your team is going to manage this MVP? This is software and it likely has a user — things will break on their own, users will break things, users will have questions/suggestions, hosting support will need to adjust… the list is very large for supporting a digital product, let alone one that is using emergent technologies like blockchains. Who are we handing this off to and are they capable of supporting what we’ve built?

The best case scenario is that you’re building your team in mirror of the team and skills that we’re using to build your MVP. What better a way to know what your team should look like, right!?

Things to know — the value of thorough discovery, timelines and budgets:

1. No matter what, Discovery (or Scoping) is imperative. You’re going to pay for this exercise regardless of it being completely detached (which we prefer) or lumped into the product development process.
2. A mistake made in conversation is far less expensive than a mistake made in code. Of course, you’re still going to have unknowns and hurdles that you’ll cross while in development, but you want as many unknowns to be a $100 discussion vs. a $10,000 rebuild of a feature. Feel me?
3. Money (the budget) is a real thing and it should be talked about as early as possible. Ideally, before Discovery is started. Why? Because we use that knowledge to aim our Discovery at building the best, most valuable MVP according to that budget.
4. A budget is often better than an open checkbook. Even if you can afford more, innovation and creative solutions are sometimes best found inside a budget for execution. Additionally, a budget will almost always produce a deadline. When you pack a V.3 into an MVP, you’ll likely miss your deadlines many times over vs. only slight slippage.
5. Team, team, team. Just like an investor will tell you, team is the most important thing. We love being the team that you’ve always dreamed of, but you’re going to need a team of your own to support this project onward.