Ask HN: Can you build an MVP in one week? | Hacker News Reader

Ask HN: Can you build an MVP in one week?

23 pointswalesj25 comments

I was just watching YC's orientation for Startup School and they kinda say we should be able to build an MVP in one week. That's not the first time I hear they saying something like that.

Now I'm wondering: am I such a bad engineer for not being able to build an MVP that fast?

I had a few experiences building MVPs but it always took between 45 and 90 days to build it.

I also tried to do the "one week" MVP a couple of times but I always got the same response from customers: we can't actually use your product without features "x" and "y", which would, then, take, at least, 3-4 weeks to develop.

I feel really depressed when I read an YC post or watch their videos because I feel like being a founder isn't for me; that I'm both a terrible founder and a terrible engineer because I'm not able to move as fast as they say we should be moving.

Am I the only one going through this?

View on HN

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.

Great description!

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

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/

That's a pretty cool experiment. Thanks for sharing. I'm gonna check it out.

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.

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

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.

Maybe you are over-engineering for an MVP?

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/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.

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?

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 to add it.

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.

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.

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.

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.

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.

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.

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.

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.

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 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.

IMO mvp should be 1 feature

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."

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.

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

Reply on news.ycombinator.com