Slimming down your MVP

Wow, you've just had this epiphany, a business idea like no other, you jump out of your chair, Eureka! Now you want to know, if it'll work, if you really should sell your neighbors cat, and tap your life insurance.

So, you sink back in your chair, call up your developer friend, and start building a minimal viable product or MVP. According to the Eric Ries, an MVP is “that version of a new product which allows a team to collect the maximum amount of validated learning about customers with the least effort”.

So, you build something, to learn. And you build, and you build. And you grow impatient, your neighbors cat dies of old age, and you've learnt nothing, because you didn't build minimally, you built too much.

That's a common fallacy for engineers. We misunderstand the quote above to mean: Product = tech. Building = writing code. So wrong. A product is something you can sell, no, not even some thing—it's a value that someone is willing to pay for.

So, before building anything at all, it's good to ask yourself those questions:

  • If your developer friend discovers LISP and refuses to work on mundane tasks and
  • if your bitcoin wallet gets hacked and half your savings disappear,

… what would you do then? How do you slim down your MVP to pocket-size, so it tells you just what you need to know: Do I have a business? Will anybody pay for this? Is this valuable?

Here an example to clarify.

Example: Financial reporting

So, you've a grand new way to present the finances of a small to medium sized business. Clarity of overview and easy spotting of red flags—that's your values. You've two companies of friends that are interested to try, if you can show something. So, to see if that's actually valuable, you build an MVP:

  • A website, where those companies can sign up for the private beta.
  • A web form where they can dump their financial date for each month.
  • A DB importer script to dump that financial data into a database.
  • Some hacked together scripts to crunch the data and generate the report data. Hacked together, because you'll iterate them with your developer on a daily basis.
  • A breathtaking reporting page where customers can see their report.


  • your developer friend discovers LISP and
  • your bitcoin wallet gets hacked.

So, instead of all the fuzz above, you decide to:

  • Visit the first company, show them an example PDF, and you discuss until they're happy with what they would get. They agree to send you their data, and you agree to give them the report within two days.
  • You visit the second company with the improved example report, same story.
  • When the data arrives, you work day and night to import and crunch the data. You ask friends, family and random people to help you in hacking together the SQL and GraphQL to get the reporting data. You create the report, a PDF, with a graphic designer friend manually. You present the report to the two companies in person.
  • Click together a landing page, where other companies can leave their email address.
  • You get feedback.

You have built nothing, because you did not have the time.

Then you send them a price indication. Are they asking for more?

They do. So, you let them send their data, and you send them the report back per mail. Your landing page is still quite useless.

Small inconveniences mount up. So you build:

  • A static web-view of the current report, because the PDF is becoming big.
  • A list of all the past reports, because your customers keep loosing their PDF.

Over time, your customers spread the word, and you can't handle the load anymore, so you decide to … not build anything, but hire a student to help you handle the incoming data, and send out the reports.

In the meantime, money is flowing in. Your hacked together scripts start being more sophisticated. The time to generate the report shrinks, as customer expectations increase.

Maybe it's time to start building something.