
Ask HN: Can you build an MVP in one week? - walesj
I was just watching YC&#x27;s orientation for Startup School and they kinda say we should be able to build an MVP in one week. That&#x27;s not the first time I hear they saying something like that.<p>Now I&#x27;m wondering: am I such a bad engineer for not being able to build an MVP that fast?<p>I had a few experiences building MVPs but it always took between 45 and 90 days to build it.<p>I also tried to do the &quot;one week&quot; MVP a couple of times but I always got the same response from customers: we can&#x27;t actually use your product without features &quot;x&quot; and &quot;y&quot;, which would, then, take, at least, 3-4 weeks to develop.<p>I feel really depressed when I read an YC post or watch their videos because I feel like being a founder isn&#x27;t for me; that I&#x27;m both a terrible founder and a terrible engineer because I&#x27;m not able to move as fast as they say we should be moving.<p>Am I the only one going through this?
======
slovette
An MVP, and the use of the acronym in SV culture, is largely an intentionally
mislabeled theory that conveniently coattails a well marketed buzzword.

What is actually meant here, is build a minimum viable presentation. It
doesn’t have to be a “product”, it’s something that adequately demonstrates
your idea enough to garner quantitative validation from your target customer.

Maybe that’s a landing page, maybe it’s a video. What it’s not, is months of
time and money sunk into creating comprehensive function before you’ve
validated value in that function.

~~~
highhedgehog
Great description!

------
davismwfl
I think their point of an MVP in a week is not that you will be able to get
customers signed up on that product but that you will be able to demonstrate
something to prospective customers and gain feedback. There is no way most
worthwhile products could even be MVP'ed where a customer would use them
within a week. I am sure there are some that have been, but my guess is they
are the exception.

One thing I have noticed, and this isn't a YC thing, but across the board with
most accelerators and VC's talking to young founders is they give unrealistic
ideas to what is possible to make founders push themselves and to think
"outside the box". I don't fault this at all, the reason is simple, most
people do not know what they are really capable of doing until they are really
put to the test and pushed to perform. So if they tell you a week and you do
something that gets feedback from prospective clients and in 30-60 days you
have something clients can actually use that is pretty damn awesome. If they
told you 60 days to start for an MVP most people/teams would flail around for
the first few weeks failing to do anything that would move the ball forward in
a meaningful way. Not out of a lack of desire to succeed but just human
nature, you start thinking about too many things and then everything gets
delayed and seems harder than it really is. If they "force" you to just start
and do something that is better than over thinking the problem and getting
stuck in analysis paralysis.

Just my 2 cents.

#edit a word for clarity

------
dvt
An MVP should be built in around one week. 90 days is definitely too long,
and, if it takes you that long, chances are that you're getting too invested.
I would say you should dedicate at _most_ 30 days to build an MVP. Longer than
that and you're probably adding bells and whistles that aren't relevant to
your core value prop.

But I agree that it's tough and you'll often second guess yourself: "Will
people _really_ pay 10 bucks a month just for a better S3 interface?" \--
Dropbox says yes. Last year, my goal was to build _something_ every two
weeks[1]. It was really fun, but also really exhausting, and, for more
complicated projects, two weeks was definitely too little time. But it's a fun
experiment I'd suggest everyone should try.

[1] [https://dvt.name/2019/01/06/retrospective-
stuff-2018/](https://dvt.name/2019/01/06/retrospective-stuff-2018/)

~~~
nostrademons
The interesting thing about DropBox was that their "MVP" was a video, and then
actually building the first viable product took 4 engineers 1.5 years.

I would say that there aren't hard & fast rules to any of this. It took Google
2 years to build their MVP, and they also had multiple grad students working
on it. The only "rule" to startups is that you have to survive long enough to
get to the point where lots of people want what you've built.

But there is a significant advantage to speed. Letting an MVP drag on for more
than a couple weeks introduces a lot of different failure modes. You get
demoralized and give up. You get too attached and fail to pivot when the
initial version doesn't work. You build something too complex for initial
users to understand. Technology changes and makes all your past decisions
obsolete. The market changes and the problem you solved is no longer relevant.
You run out of money.

~~~
dvt
This is a good point. To wit, I'd say the Google MVP was _probably_ the
Stanford PageRank paper.

------
git-pull
It takes 1-2 days just to get a frontend setup working the way I want. What
create-react-app / @vue/cli gives out of the box isn't sufficient if you're
connecting to a backend.

I like graphql in the backend and having it generate a schema file, and
getting typescript typings from that, so all the data structures align nicely.

Add pushing to heroku / some cloud service via fabric, that'd easily put me at
1 week.

It's _after_ the first week stuff really comes together. Then there's a
reliable hot reload loop, scripts, familiar stuff you're used to is prepped.

I don't like the 1 week thing because I think you'd be stuck inside a
framework/starter kit that'd hold down what you want to build. I think a month
is minimum if you wanted to impress and get your idea across.

~~~
StriverGuy
Maybe you are over-engineering for an MVP?

~~~
git-pull
The stack I suggested _is_ opinionated for an MVP. I won't defend something so
specific to my personal case.

However there's more than that at play. Let's just assume bootstrapping the
basics, with a requirement there's a backend and it has to be deployed:

1\. If there's a requirement to have a backend connection and deploy the mvp,
that rules out create-react-app / @vue/cli in most cases since it'd be too
custom. The app would need to be ejected. But even further, the ejected app
_is_ overengineered.

The byproduct of create-react-app's ejected output is so bad I wrote
[https://github.com/tony/react-typescript-vanilla-
starter](https://github.com/tony/react-typescript-vanilla-starter),
[https://github.com/tony/vue-typescript-vanilla-
starter](https://github.com/tony/vue-typescript-vanilla-starter) simply for
the sake of getting a minimalist webpack+typescript+hotreload+prod build
config working.

I found it challenging to patch together webpack + ts + react/vue from
scratch.

2\. Going to a stack outside of our usual stack takes time to relearn. Not
necessarily a bad thing, but people are going to be rusty.

~~~
wishinghand
I can’t understand what you mean by the Vue or React apps being insufficient
if there’s a backend. What else would they be except an interface to an API?

~~~
git-pull
My point is - configuration takes time. Having a dev loop to gain velocity is
necessary, as is having to deploy. I believe MVP's flouting 1 week figures
aren't going that far. Maybe showing it off during a presentation. I'm
assuming a public demo with a backend where you can share the URL,
register/login, etc.

Te output having to land somewhere. (More than half?) the time pushing dist/
files to a static host won't cut it, even for an MVP. From the beginning, the
quickstart tools and workflow become a burden. Cases vary widely, here's mine:

With create-react-app, I don't want to use the included index.html / default
dev-server config. I'd be using django-webpack-loader to load the webpack
entrypoints. That requires webpack-bundle-tracker [1]

In my case, it'd also involve compiling via webpack, collecting static files
and pushing them to S3.

[1] To be fair, you could use [https://github.com/timarney/react-app-
rewired](https://github.com/timarney/react-app-rewired) to add it.

~~~
wishinghand
I don't quite follow your issues, but when I use Nuxt (a SSR config for Vue),
I can get the basics of the app interface itself in a day, polishing on the
next day or so, and then I can work on getting the endpoints I stubbed out to
work on the backend, or hopefully a dedicated backend dev has worked on that
concurrently. Basic login and authentication will add another day or two.
Whatever ejecting is doesn't come into the equation, and I can get the hosting
instantly on Now.sh.

------
BjoernKW
What's the definition of an MVP, a minimum viable product?

According to The Lean Startup by Eric Ries it's - and I'm paraphrasing here -
the minimum set of features that allows you to validate a marketing
hypothesis. An MVP therefore can be considered an experimental setup that
allows you to measure and learn in order to use that information to build a
better product in the next iteration.

How that validation and the minimal setup required for it looks like entirely
depends on the product, which is why setting a hard time limit that's equally
applicable to each product category probably isn't going to work.

The shorter the time between turnarounds (i.e. between build-measure-learn
cycles) the better.

Some of best initial MVPs are simple websites describing the product and
showing a call-to-action button. If a sufficient number of potential customers
click that button that's validated learning and an indicator for you to build
a more sophisticated version of that product.

------
codegeek
Don't overanalyze this. Build something and have a plan to release it say max
within 90 days. Not all MVPs can be built in a week in my opinion. Think of
this way. You may still be thinking about this 90 days from now or you will
have released something. So what it took 90 days. You have made a start. No go
sell.

------
segmondy
If you get a customer saying they can't use your product without features x
and y. you have an MVP, the point is to get valuable feedback, you could have
built feature a, b, c, d and e when they wanted x and y. MVP saves you the
time, of course customers can be BSing, so if you can get them to sign letter
of intent or give you some cash to deliver x and y before you even begin, the
better!

If you only hit up a few customers you might hear such objects, but with an
MVP, the idea is also that if you have a large enough market, you will
certainly find some customers happy with it as is. If you reach out to 100
customers and they all refuse because they need some other feature, you're
probably on the wrong path.

------
simplecomplex
It’s not good advice. It’s misleading, a poor generalization, and entirely
misses the point of what an MVP is.

An MVP is not defined by time to build, but by the minimum necessary to build
to make the very first sale. MVP is the minimum necessary to capture the
Minimum Viable Audience. That could be a landing page or it could be a
spreadsheet or it could be a complex app. It could be a game demo. The point
is only build the minimum to be able to capture a customer and iterate.

An MVP _is not_ associated with a time frame at all. YC is wrong. Just read
The Lean Startup which popularized the term.

As a founder I’m pretty sick of these unrealistic platitudes tossed around by
VCs and accelerators. It’s not educating anyone.

------
losthobbies
Nope :)

I'm trying to get my MVP out the door too and while I could probably code
something together, I'm thinking about just using Airtable and some forms to
get started. I'm getting distracted trying to decide on a technology stack (I
work with .net but would like to try something different).

It also depends on your current situation. I'm working full time trying to get
a project finished and I have young kids at home. I can barely stand up right
now.

Best think to do is just keep going. Forget about the week thing. If you are
dealing with customers it sounds like you have an MVP anyway - you just need
to add a few more features.

------
QueensGambit
I think MVP is for validating the need. Not for solving the need. If your
customer says: we can't actually use your product without features "x" and "y"
and then adds: "when can I get those features?", you are on the right path.
You can go on to build the features to get him to use it (Many others will say
the same thing and you will see a pattern emerge). If he uses those features
as an excuse to say "no", you have failed the validation test. You need to
look for other problems to solve.

------
tdevito
Every project is different. Are you building a simple social networking app
with basic auth and db? That should not take more than a week or so to build
and launch. On the other hand, building a search engine or a semi
sophisticated ML system will most likely take a month or more.

------
saluki
Don't feel depressed . . . you're only seeing the success stories, there are
lots of us out here who have failed at building an MVP, a SaaS a Startup
(multiple times). You just have to keep at it till you get the right idea at
the right time and execute on it.

You probably can build an MVP in a week, but it depends on the idea you're
building out too. If you need 2 to 4 weeks doing it part time, do it. The key
is executing on the idea, testing out your product market fit.

You'll always have users saying I need x, y and z to use this.

You don't have to be in such a hurry.

If you haven't heard @DHH's startup school talk check it out
[https://www.youtube.com/watch?v=0CDXJ6bMkMY](https://www.youtube.com/watch?v=0CDXJ6bMkMY)
it's still inspiring.

Check out the startupsfortherestofus.com podcast. You can follow Rob from drop
shipping beach towels, to buying SaaS apps to founding Drip and having an
exit. Great info and advice.

------
dylanhassinger
IMO mvp should be 1 feature

~~~
walesj
What if that 1 feature alone isn't useful to customers? For example, they
explicitly say (after your 1 feature MVP): "this is great! but we can only use
it after we have all those 4 features we asked."

~~~
nostrademons
Most likely there isn't a business there. If prospective customers say "We can
only use it after we have these other 4 features", then chances are, when you
build those 4 features, they'll say "we need these other 5 features and then
maybe it'll be useful".

There are some exceptions, and some really prominent startups (eg. Reddit,
AirBnB, and Twitch) that took off after adding certain features, but usually
they had an initial version that was halfway-promising, and they decided on
the additional features by observing what people were trying to accomplish
with the product rather than by asking people. There are other companies (eg.
Instagram, Whatsapp, AirBnB again) that became popular by _taking away_
features.

Typically what's going on with the "We need X, Y, and Z first" crowd is that
people start comparing your product to existing products in the space, and
then suggesting all the other features they have. If you start going down that
path, you'll never catch up, because by the time you implement them, the
product your chasing will have implemented new stuff. You need to enter _new_
markets where there isn't a standard competitor that you'll be measured
against - but that means that a good number of ideas you'll think up won't
actually be useful.

------
mars4rp
that's why we have millions of uber for X and not enough robots!

