MVP Development: Scope, Build, and Launch

A minimum viable product is the smallest version of your product that real people can use and learn from. Its job is to test your riskiest assumption quickly. Cinekit, a camera gear rental marketplace we built, shipped in one month and has since grown past 100,000 users. Here is what made that possible, and what we tell founders now.

1. 01Start with the riskiest assumption

   Write down what must be true for the business to work: that a group of people has a problem, will use your product and will pay for it. Pick the assumption you are least sure about. The MVP exists to test that one.

2. 02Build one flow end to end

   Cinekit’s first version did one thing: list gear, book it, hold a security deposit through Stripe and return it. Money Ball, an NFL stats chatbot, took three months because it did one job, answering questions from a live database. Build the one flow that delivers value before anything around it.

3. 03Cut scope on purpose

   For each feature, ask whether the core flow works without it. Admin tools, extra user roles and integrations can often wait, or be done by hand for the first users. Every outside system you add brings its own rules and failure cases, which is one of the main reasons projects run long.

   Building in increments helps too. In an in-depth survey of software projects, those using incremental or evolutionary models had smaller effort overruns than sequential ones (Moløkken-Østvold and Jørgensen, 2005 (opens in a new tab)).

4. 04Choose proven technology

   An MVP is not the place to try a new framework. We built Cinekit on Ruby on Rails, which suits fast backend delivery, and used Stripe instead of building payments. Spend the engineering time on what makes your product different.

5. 05Measure from the first user

   Decide before launch what success looks like, and track it from day one. On a booking site we run, the data showed half of all giveaway entry attempts were failing, mostly because phones gave no clear sign of a missing field. After one fix to the form, the next 14 entries all went through.

   Numbers show you what people do. Conversations with your first users tell you why.

6. 06Plan for what comes after launch

   Launch is the start, not the finish. Our three longest projects each had a first version live within three to six months, and at least 70% of the time on each came after launch. Most of our builds take three to six months, and simpler ones take one to three. The full data is in how long software projects take.