
Ask HN: How much work do you put into MVP? - barelyusable
Wondering how much work you&#x27;ve put into MVP to validate your idea, and how did you do it: mockup, video, prototype, doing stuff by hand with a primitive system.
======
goldenbeet
mine came from a hackathon. (for reference it was an online tournament
platform) So it was two people and 48hrs building mocks, getting basic stuff
rendered and implementing live reloading in browser (one of the main points
for our idea). We ended up winning the hackathon (over 100 teams) so we
considered that "validated" and decided we could try building the rest of it.

Spent another weekend building out basic functionality (login/register for
tournament/report scores/"staff" ability to resolve disputes) Then we reached
out to a gaming league who held tournaments three times a week. They used it
had some issues, we fixed them. Opened it up to two more leagues and they all
loved it and wanted to start putting money into it. This was the point when we
felt "validated" again and considered this our MVP.

At that point it was about 6 days of coding and about a month of testing with
these three "clients". We then ran with that MVP for another month, opening up
to more people, and collected feedback before doing another round of coding.

------
tabeth
Unfortunately there's no good general answer to this. One could say an email
blast with a _description_ of what you're trying to do with a credit card form
would be the least possible work you could do. You're unlikely to get any real
response from that method, though.

Others will say a fully functional prototype of what you're set out to do is
what's necessary in order to fully allow prospects to understand what you're
trying to do. Sadly this requires a lot of work which probably will be wasted,
unless your goal was to simply to do it, and not to build a successful
business as soon as possible.

in short, i'd say there are three criteria:

1\. how long would it take you to make a functional prototype?

2\. what's the potential upside of a good first-look?

3\. what's the downside of a bad first-look?

------
canterburry
Who here feels MVPs aren't MVPs anymore?

The expectations of MVPs from just about everyone have gone through he roof.

~~~
lvspiff
Very much so - I'm stuck on the periphery (operating the environments the
system touches for data) an endless MVP...1.5 years when the initial sprint
was 6 months. Management keeps adding more features before wanting to release
it to a test group yet keep calling it an MVP. New teams are being brought in
and have to be retained. New management is brought in each time with more
ideas of what is "minimal". Yet they keep throwing money at it...

~~~
BjoernKW
MVP is the new prototype, or so it seems. Remember, there's nothing that lasts
longer than a prototype in production.

------
1ba9115454
For me an MVP is a full application. One that a user can signup and actually
use. So typically I'm looking at around 3-6 months of development.

~~~
reading-at-work
Agreed. "Minimum Viable Product" means it's viable, i.e. people can use it.

------
karthiksk2012
I don't think landing page with an email subscription is an MVP. Many people
have done it and it definitely helps in gathering an audience and get your
initial users, but it won't help you in understanding your product. Product is
more than just users saying ok to try a product. It's about the will to pay or
engagement. I think a working product with minimal core features can be called
an MVP. The feedback from users after I launched my product* is what defined
it. *[https://pipecourse.com/](https://pipecourse.com/)

------
jwilliams
Seems that MVP is pretty much whatever the situation dictates. So I'll avoid
getting to philosophical.

In my last case (funded, growing B2B SaaS company) we built prototypes on
"paper" (actually mockups designed for an easy display on iPad). We then went
out and pitched potential customers on the back of the prototype. Criteria was
getting them to emphatically commit to the product if we were to build it. We
were pretty strict on what commitment meant. Probably 1-2 months work.

When we hit the threshold, we built the minimum required, went back to those
parties, closed the deals and worked out from there.

~~~
zer00eyz
1-2 months of work building the prototypes or 1-2 months of work building,
iterating and getting commitments, or 1-2 months of work building a launchable
product based on them?

Paper prototyping is HUGE. I don't get why more folks won't or can't embrace
it. Not only can you do the testing that you have suggested but your engineers
and designers will THANK you.

There is a huge upside to paper, UI issues can be spotted early and cheaply.

------
mindhash
I have spent usually between 1-3 months to build MVPs..but you can't
generalise as it really depends whats viable. Talk to your prospects to define
what is viable. For enterprise softwares its usually longer due to various
reasons.

My first product was into travel and we spent months just to build MVP that we
thought was viable. Stupidest thing we could do. The product didn't go
anywhere.

Second product was into logistics. I spent most of my initial month travelling
in field with my cofounders and doing stuff manually. This helped me
understand what was viable and build product in a month's time.

My third product was education platform. This was a funded startup so they had
sales people. I used them to gather information. Like what profs think about
the problem space, what students think then what type of devices are they
using, do they have good internet access. This greatly helped us figure out
whats minimum that we need in product. Like we discovered that students in our
country rarely have a laptop or desktop. They use desktops in school's lab.

My current product is about team productivity. I am on call with most of my ex
colleagues, friends to figure out what would be minimum. My problem statement
is kind of validated as most have felt a need for solution.

So spend more time with prospects to figure out MVP or MRP (Minimum Remarkable
Product).

------
mooreds
As little as possible if it is a true MVP. The goal is to test the business
idea.

If possible Google forms plus shlepping.

~~~
maxxxxx
I think that's the way to go. From the outside it looks like the real thing
but internally it's the bare minimum. But you have to be ready to scale up
quickly if needed.

~~~
mooreds
I think, based on experience and reading, that "being ready to scale up" is
nice but you'd be surprised at how much you can do with email.

------
meesterdude
First, I would consider the benefits of building it anyway
[https://medium.com/you-could/build-it-
anyway-6c43486e8a74](https://medium.com/you-could/build-it-
anyway-6c43486e8a74)

When I built my project for behavioral and cognitive changes
([http://willyoudidyou.com](http://willyoudidyou.com)) MVP for me was
something that _i_ could use, would want to use, and that would actually do
something useful for me. Specifically, I needed to see a change in my
behavior. I needed to brush my teeth before bed, do laundry with regularity,
and eat healthier. I just needed someone (or something) to help put those
things on my radar when they needed to be.

I reached MVP when there was nothing else that I needed to add, feature wise.
Sure, there are things I WANT to add, but building out the core was important
for me.

Before I slung most of the code... I had done some prototyping. Html/CSS files
that I chopped together and tinkered with. It went on to influence the actual
buildout, but was more of help with my own brainstorming.

------
sibmike
It depends on what you want to test. Atm, testing an idea is easier than ever
before, but shipping an MVP gets harder every day. To test the underlying idea
we asked contractors to fill in prices in Google sheets. After that we have
spent 2 years building our MVP. People expect you to be as useful, adaptive
and intuitive as unicorns from the very start. (Looking back, we could have
ship it faster, but as always you know which edges should have been cut post
factum) Imho.

------
tmaly
I really try to do as little as possible. You learn over time that it is
better to launch early, get feedback, and iterate.

There was a great write up recently on indiehackers.com with Jeff Atwood about
Discourse. He shared some of the older landing pages he first put up in the
comments.

It is really a testament to launch early. If you look at Discourse now, its
night and day from when it first started.

------
taf2
I think it depends on your definition of MVP. Some are prove to an investor
you have a good idea. The kind I like are good enough for your first 10 or 100
customers... time to complete really depends on the product. IMO the MVP
should be the basis for all future work e.g. After this first step you are
incrementally adding improvements

------
j45
There is a good book called Lean Product Process that I recommend. $15 and a
few hours will help you find how much MVP you need to test hypotheses with
customers.

------
charuthomas
We did a basic 'demo' version of our product; it was very simple but had all
the aspects of the full product.

------
greato
MVP is minimum measurable product. When you have analytics set up, you are
ready to launch. (mailing list)

~~~
barelyusable
So just landing page + mailing list "subscribe" button + Google Ads to drive
traffic?

------
jhwhite
The minimum amount of work.

~~~
jjn2009
While this may be simply put this really is the best answer. The least amount
of effort it takes to push something out the door is the ideal MVP, market
validation is many times more important than early stage tech/code in a
business, code quality at such stage does not correlate strongly with the
success of a business idea.

Whatever it takes to get feedback from someone is the amount of work that is
needed. Which means you can throw out 90% of the features and anything that
even some what resembles an optimization of code, coding processes or business
processes.

------
jameslk
That really depends on what kind of MVP it is and what you're bringing to the
table. Some startup ideas can be hacked together quite simply by reusing a few
existing services, tools and a bit of programming. Others may require some
prototyping and fund raising (e.g. hard tech). Whatever it may be, the MVP is
a hack and experiment to prove product-market fit. It's the tiniest, minimal
effort you can expend to build a test to prove that there are real people who
desperately need something you could provide them.

An MVP is more marketing and sales than it is developing. Building your MVP
should consume a fraction of your time and resources compared to the effort
you'll spend trying to get people to see your hack and validate it. It's more
market research than product development. You just want enough proof there's a
business opportunity to continue spending time, money and energy on it.

For software startups, there's a few patterns you can employ to build an MVP.
One of them is the Wizard of Oz test, where you provide a facade of a real
product but do all the hard work behind the scenes manually (until you can
automate the rest of it). Another is piggybacking on other existing services
and solutions, modifying them to your specific business domain (e.g. form
builders, communication services, integration services, open source, BaaS,
etc). Then there's the launch page strategy, that attempts to lure sign ups or
"beta subscriptions" to show demand without building anything more than a few
prototype designs and a landing page.

It seems more compelling to just build it from scratch, but researching
options and planning a more clever solution may save lots of development and
money down the road. Treat it like a science experiment with incremental
solutions and gather as much feedback as possible.

There's quite a bit written about building MVPs. Here's some resources and
inspiration:

\- _Lean Startup_

\- _Sprint_ (Jake Knapp)

\- Product Hunt Began as an Email List:
[http://ryanhoover.me/post/69599262875/product-hunt-began-
as-...](http://ryanhoover.me/post/69599262875/product-hunt-began-as-an-email-
list)

\- Building Your SaaS Startup’s Launch List:
[https://medium.com/@cliffordoravec/the-no-bs-approach-to-
bui...](https://medium.com/@cliffordoravec/the-no-bs-approach-to-building-
your-saas-startups-launch-list-part-2-of-the-epic-guide-to-8cc371be772c)

\- Successful SaaS MVPs: [https://belitsoft.com/custom-application-
development-service...](https://belitsoft.com/custom-application-development-
services/successful-saas-startups-mvp-lean-paying-customers-first)

\- Wizard of Oz test: [http://blog.ycombinator.com/ask-yc-upfront-technical-
investm...](http://blog.ycombinator.com/ask-yc-upfront-technical-investments/)

\- Shameless plug--I wrote more about MVPs here:
[http://jameskoshigoe.com/how-to-build-an-mvp/](http://jameskoshigoe.com/how-
to-build-an-mvp/)

~~~
maxxxxx
"launch page strategy, that attempts to lure sign ups or "beta subscriptions"
to show demand without building anything more than a few prototype designs and
a landing page"

I think this is totally overused these days. It was OK the first few times but
now I feel sort of used when I see this.

~~~
jameslk
I agree it's a bit cliché and can be annoyingly deceptive, but there's less
shitty ways of doing it, which is discussed in that SaaS Launch List article.
Regardless, if it works, I wouldn't discount it. It's basically just a ghetto
Kickstarter campaign page. I'd rather employ that trick than spend a few
months building an MVP just to find out nobody cares. I've done the latter
enough times to know how much it sucks when you're wrong about your
assumptions.

