MVP Development

There are a number of ways to build your MVP, and each might have a different pricing structure. But here I try to lay out some rules of thumb on how to get budget ballparks for certain features.

There are a number of ways to talk about essentialist MVPs. Minimum Viable Tests and Minimal Minimum Viable Products are popular. Here I want to explore this concept a bit further and compare a standard approach to focused one.

When constructing the backend architecture for a system, keep the concerns separated. This is a general principle followed in containerized designs, but holds true down to smaller components. Even if the component isn't far away and different, keep responsibilities relegated to separate files or directories.

Much of my focus is reducing the scope of MVPs and getting really essential. One method I want to explore here is what I'm calling reverse scoping. Instead of starting with all the hopes and wishes for a product, start with the time and money you have right here right now. What can you build with that, however small, to increase your commitment, increase the investment others have made, and build out something bigger.

We've built dozens of MVPs, some were brand launches at Google, some startups that raised $3M in funding, and some productivity tools we conceived that got acquired by bigger companies. Here's some of our hard won knowledge about building a product from the software perspective.

MVPs are constantly changing to adapt to the market and needs of users. You have to be very judicious in your testing, so that you don't waste valuable cycles on things that will be thrown out soon after writing, or something that just lengthens development time beyond what the market can bear. You don't want to be crushed by a competitor because you were writing duplicate unit tests for your backend that will be rewritten in a month. That said, I'm going to go through the major types of testing, and when they'll be useful in your product lifecycle.

Doing a competitive analysis on your MVP and business idea yields many benefits. It helps identify gaps in the market, shows where the attention and money is focused, and may expose features that are extremely technically complex. It's a good thing to do before starting building your MVP to ensure you're hyperfocused on your unique value proposition.

When building an MVP, you want to steal as much code as possible. You're not worried about code licensing, you want to validate the market as quickly as possible with open source. So you want to use third party libraries to do the heavy lifting in your app. This is the heart of most great new companies, leveraging an emerging technology to serve a new market. Uber didn't build a GPS mapping system in its first version. Google didn't build an NLP system in its first version. Netflix didn't build a facial recognition library for identifying actors in its prototype. You shouldn't either. This article gives a few tips in identifying and using existing libraries for your MVP.

There are lots of ways to get an app built. I explored some tradeoffs in my article on outsourcing vs hiring inhouse. Here, we're discussing the advantages and disadvantages of dev shops and hiring single contractors.