How Much Does it Cost to build an MVP?

In this post, I will cover a couple of practical tips on choosing the best approach for your software development project. It is essential to start your development project on a sound footing, as this will set the tone and impact you years into the future. This article continues a previous post – “How to reduce the cost of software development” – and I will continue with that theme.

Be realistic with your timeframes.

A developer will propose a development approach and outputs based on the (time and budget) constraints you provide. If you are not realistic about your timelines, your developer may propose an inefficient approach or sub-optimal outputs and waste a lot of time and money in the long run.

For example, let’s say you have five months to deliver a project but tell the developer you have three months. You assume this is a good negotiating tactic because:

• The developers will be more aggressive with their timelines
• The more aggressive timelines would reduce your costs
• You’re allowing for a risk factor in case of things “taking longer” or “costing more” than you anticipated. So you want to add in some safety buffer to cover yourself.

Although it’s good to be conservative with your estimates and set some contingency time and budget aside – overdoing this could end up hurting you in the long run. Let me elaborate.

Continuing the above scenario, a developer may propose an “out-the-box” approach instead of a custom-build process. The “out-the-box” method may start presenting development constraints – 6/9/12 months into the future. At that point, you would be faced with a tough decision. Do you throw everything away and start from scratch? Or do you continue down the path and try to bend the “out of the box” solution to your will? What happens when you’re struggling to differentiate yourself from the competition because of the limitations of your previous decisions? Or if you need to do a drastic pivot based on market feedback?

I’m not suggesting that a custom build is always the correct choice. By being open, honest, and realistic, the developers will provide you with more, or at least more, suitable options. Still, by incorrectly stating your constraints, the developers will take specific approaches off the table, ultimately limiting your options.

How long do things typically take?

It would be helpful if you approached a development project with a sense of realism. Suppose you have an idea of how long things typically take and an understanding of your various options to approach a project. In that case, you will be empowered to make better decisions and have more meaningful discussions with your developers. You will also provide them with some comfort that “you know what you are doing,” which would reduce their risk factor in doing business with them (which affects costs).

As an extreme example, if a customer approaches me and asks me “how much money it would cost to build something like Facebook” and expect a product to be delivered in 2-4 weeks – I would flag that customer as a super-high-risk proposition – because they have no idea what they are doing. Yes, this happens all the time.

Sizing the project – key features

To say it: keep it small. It’s great to invest a lot of energy into your big picture and build out the product roadmap, but every project needs to start somewhere – you’re not going to build the whole thing at once. There will be one key feature and some obvious, essential things you need to develop to support that key feature. For example, if you want to build:

• In a social app, your core features could be user profiles and a news feed
• For a commerce product, your core features would probably include something like a catalog and products
• In a communications app, your key features would be profiles, and messaging infrastructure

Sizing the project – supporting functionality

Based on the above, you can make a couple of other assumptions:

• You’re probably going to build an “acquisition” flow – attracting new users to your product
• Users may need to create accounts, log in, reset passwords, maintain their information
• There will probably be a back-end with administrative functionality
• There could be a website, mobile site, and a mobile app
• And you are highly likely to need analytics or custom reports – there’s no point in building something if you cannot measure its performance.

If you combine the MVP functionality and the “supporting” functionality, you typically end up with somewhere between 4-7 features – your project scope. It isn’t easy to build anything useful with less than four features unless you add functionality to an existing product.

Options, Approaches, Timelines, Outputs, and Typical Costs

There is some flexibility in how you approach a software project, depending on what you want to achieve and how much time and money you have. A typical software project usually combines a number of these processes, producing deliverables in succession.

Based on the same project scope above, here are some of the typical processes you can run and what the requisite outputs could be:

These numbers are indicative, of course, and will vary depending on the specifics of your project, but they give you a general idea of what you’re looking at.

What’s the best approach for you?

This topic warrants a full post but can be summarised as follows

• Wireframes are good for “figuring out” your scope and primary user flows. This would also allow you to get closer to the actual project cost – by reducing the uncertainty factor applied to the estimations
• Designs help you visualize the product and can help gain early interest in the development, communicating the functionality to visually oriented people
• An Interactive prototype gives you a natural feel for how the product would function and how users would find their way around the interface. Prototypes can be used in the User Research part of your project too. Making changes to your user flows and designs is still relatively low-cost and low-risk at this project stage. However, it’s not a necessary step to continue with the development.
• Out-of-the-box products are built on existing technology, usually intended for this purpose. A simple example is to use WordPress for a web CMS, Magento or Shopify for eCommerce, etc. An out-of-the-box solution will get you going very quickly, but you may face some flexibility constraints at some point in the future. It’s typically an interim solution.
• Custom MVP products are custom-built products. They typically take longer to build than out-the-box solutions, but they give you more flexibility to build upon for the future. An MVP product is not meant for commercial release; it may not be ready to scale and utterly polished from a user perspective.
• The MMP is the product that you can start planning to monetize. An MMP is ready to go to market and scale. It’s important not to confuse the MVP with the MMP – you will not be able to scale and roll out the MVP for mass consumption.

Approaching developers

Now that you know what various approaches are and what you can expect to have as output, you can start engaging developers.