How To Build A MVP Quickly

I love photography. In fact, I love using photography in my designs for websites I build. One thing we can all agree on is that stock photography is awful. And it’s expensive. It is generic and in some cases you see images on your site on others.

Some other folks noticed this too. So they thought that because other people might think this was a problem they needed a way to figure out if this was true. They set out to build a website where you could get photos for free.

Rather than spending weeks or months creating a website that could totally be a flop, they set up a free Tumblr blog, spent $20 on a Tumblr theme. They then worked with a local photographer to create 10 hi-resolution photos and uploaded them to the website. Within 3 hours, the first version of Unsplash was built.

What is an MVP?

This story highlights what we call MVP or Minimum Viable Product. So what is an MVP? An MVP is first and foremost the race to deliver customer value. A Minimum Viable Product is that version of a new product which allows a team to collect the maximum amount of validated learning about customers with the least amount of effort.

An MWP is the first version of the product you are building that solved your grand problem. In other words, it’s really on the core feature set to make the product work. It can be a website or an app, but the goal here is to keep it simple.


At this stage in your development process, you are saving time and money by building an MVP. That doesn’t mean you can use it as an excuse to build a bad product. You still have a goal of making sure it fits the value proposition you put forward. What it means is that with each feature, each potential page your product could have, it should have the essential things to prove people want what you are building.

A good question to ask yourself is, “What could we make at a minimum to get our product functions to prove it is a solution to a problem?” By thinking about this question, and being able to answer it, you help to spend too much time building lower priority things early on.

Let’s go back Unsplash for a moment and analyze it.

  • The Unsplash MVP took just 3 hours to build.
  • They used Tumblr, a free blogging tool, and a $20 theme.
  • They hired a local photographer to take 10 hi-resolution photos.
  • They uploaded their 10 photos to the site for people to download them for free.

I don’t think I’ve seen another MVP built in such a short time that has become such a wild success. Now what’s even better is that when they were finished with their MVP product, they submitted Unsplash to Hacker News. Hackers News is a place where they felt people might be interested in what they were doing and the problem they were trying to solve.

Within hours of the post, over 20,000 photos were downloaded. Even though the first version of Unsplash was primitive and barely worked, it was enough to provide that it was solving the problem they set out to solve.

I think what’s even more credible is that today over 2 million photos are downloaded a month. And that simplicity of Unsplash is what made it special.

The story of how Unsplash got started is inspiring. It teaches us that sometimes you don’t need to design or code anything to prove that your solution is useful. But how do we determine what an MVP of your product will look like? Is there a framework that we can use to help us better understand what we’re going to build? Almost like putting a box around our MVP.

Keep It Simple

Thankfully, I’ve found over the years of building products that you can use the following process to help you build your MVP.

  1. Start with a single, simple product solving a tiny subset of your grand problem.
  2. Keep iterating, while constantly solving bigger, related problems en route to solving the grand problem.
  3. Constantly communicate the vision of the grand problem that your product is solving.

Wrapping Up

My experience with building products is to build your MVP first and continually add more to it. The most important aspect is to get out your product quickly to test your assumptions. This allows you to not spent a lot of time up front building our product while letting you start to get feedback on your product.