MVP takes more than a month?

by SofusPolt. Posted on Sep 13, 2020    7    19

I heard an MVP should not take more than a month for it to be called an MVP, although my product will definitely take more than a month because the core concept of it requires alot of manual work.

I know MVP stands for minimum viable product, but I can't release it if it doesn't do the thing it's supposed to do right?

Should I just keep working on it until I actually have the earliest testable product, even if it takes way more than a month?



I'm on month 3 of building my MVP for . But I'm relatively sure there is a market. It's also not something that can be done manually, or faked with Google sheets and a person.

Just build it as fast as to reasonably can.

aradil 1

Killer feature for your app: automated no-pants detection that disables your camera.

tengable 1

Thanks, I'll make sure to get that in before the MVP

Dabellator 1

I worked at 3 startups who focused on building an MVP in order to test the market. They all had the resources to do so from other avenues, meaning the MVPs that were being built were all ventures into new territory. In each case, building the Minimum meant that at each step, whenever we were confronted with a question, we favored time and took the easy route. Our plan was always to come back to these little questions once we had enough "user feedback," and make a better feature for v1.

The problem is that the apps never really worked right, because of all these little questions that got skipped. There was no product market fit, because we were trying to discover a product in order to find a market. It was all guesswork!

I've always approached the idea of MVP a little differently, and these experiences have only fed that concept even more. An MVP is just a research tool. In that sense, it's not really a product. Products today have so many aspects that are expected just for bare minimum, like user profiles, notifications, authentication, payments, support... I think your MVP should just focus on communicating the core concept of what you are trying to introduce to the world. And if you have multiple features, break each one out into a testable "MVP." These MVPs are really only for beta testers, and may not even be digitized, it might be instructions in a google doc. Use that to discover as many unknowns as you can. And yes, each of these beta MVPs should be around a month, give or take.

Then, go build a killer v1.

blueberrywalrus 1

Obviously, the shorter it takes to build an MVP the lower the risk of your overall project, but there are plenty of product spaces where table stakes for an MVP is far more than a month of work.

Really, it is just the longer you take to build and MVP the more important finding other ways to lower risk becomes.

ZaurbekStark 1

You have to know exactly what you want to validate with your MVP. Usually, it's the minimum set of features you need to build to give some value to your users. That's it.

An MVP is meant to be quick, something that can be done in days or weeks (the first version at least) and then you iterate over it. Your first MVP can be a simple landing page, a video, or a basic app.

Check out the video of Michael Seibel from YC on their youtube channel, he talks about what an MVP is, and how you should approach it, very helpful

_DarthBob_ 1

As someone who spent a year building an MVP, don't do it.

We made a product, we invested a lot into it and we managed to force sales over the line but it was a big uphill struggle. Main problem is that while our product solves a very real problem, people like that part of their job and don't want to automate it.

Fast forward to 3.5 years later and COVID-19 slowing things down. In 2 months we've made a new adjacent product MVP, feedback has been stellar. This is the problem they wanted solving all along and we could have started here.

They're both part of same big solution and we could have started here. The main mistake on my part was biting off too much in one go and not putting enough effort into something that we could have validated much quicker. Once we'd spent a year building the damn thing we then spent another 2 fulfilling the vision thinking the incompleteness was the main blocker. After putting so much effort in it can be very difficult to change direction.

I was adamant when we started that the original solution was the thing we needed to build I'm sure it will be very difficult for you to see past your vision right now too but I challenge you to think about the full solution break it down and come up with a smaller piece of the puzzle that would form part of the bigger solution. Then build that quickly talk to your audience and listen to the pain points they point you towards iterating quickly.

Good luck!

Manureprenuer 1

The MVP does not need to be perfect. You'll probably learn more form the feedback of the customers.

peppercorn700 1

"If you are not embarrassed by the first version of your product, you have launched too late" - Reid Hoffman

I would keep working on it until you have the bare minimum product, don't spend ages trying to make it perfect and be wary of feature creep causing delays.

GaryARefuge 3


  • Minimum (the very least amount of effort required)
  • Viable (it must be functional)
  • Product (you can generate revenue)


    Most often people don't understand what each of these things represent nor how they work together.

    Most often people are overthinking shit.


    For example, the MVP of my last startup was a contact form wrapped in phone gap to look like a iOS app. 99% of our operations and functionality happened outside of our "app" through manual means.

  • We told our potential clients that we were selling our services to that our app use fancy software to increase efficiencies and give them a better experience.
  • All the app did was collect key information from the client and email it to our dispatcher.
  • Our dispatcher did all the computing with our manual systems.
  • The systems worked. The clients got what we promised.
  • We had a MVP that didn't take a lot of time to code because I understood that such systems utilized by any software could also be utilized by human beings manually. Our MVP allowed us to generate revenue, validate our systems work (before automating them), validate the market wanted our product/service, and allowed us to generate some traction that we leveraged to raise a seed round.

    My current startup has been following a similar approach. Designing and testing systems and experiences without any proprietary software. Validating the market wants what we have to offer. Generating revenue. Generating traction. We did this within two weeks. If we focused on building out a proper digital platform automating these systems it would have taken months if not a year +

    You don't need to launch a MVP that is fully digital nor proprietary. Don't forget that any such software requires systems and algorithms. Don't forget any such software is a tool to raise efficiencies.

    Even if you insist on building such software right out of the gate you can almost always scale that build back by substituting key things for manual alternatives or by utilizing software someone else made already to provide that support.

    That doesn't mean you steal someone's thing. You license it or you buy it or you use something that is offered to help for free. You can cobble existing things together to create the unique experience you want to offer to the market.

> I heard an MVP should not take more than a month for it to be called an MVP,

Heard where? lol

Arbitrary rules and timelines make no sense. The very premise of that statement is absurd. 1 month with 1 person? 1 month with a team of 100?

4_teh_lulz 2

Depending on the complexity an MVP can take a day or a year or more.

With an MVP, the key is to not deliver more than you minimally need to test the market. i.e. if you'r building an app - you don't need dark mode for iOS users. You probably don't need fancy account management tools. etc, etc.

pixelrow 4

A rule of thumb for development time of a startup is asinine.

orbit99za 9

Yes, I have spent a year, to MVP. You can't test the market with something that doesn't work.

Cultural_Beyond8851 12

The startup world suffered with the introduction of the concept of an MVP. A so called mvp Does not replace due diligence, interviewing your target market, pulling out objections and validating the concept BEFORE building anything.


I dislike this concept very much. Unless it applies to you, you can’t sufficiently test certain products without actually having something to test with. Some ideas can be validated and iterated on without any actual product, but others just can’t. Imo it’s all about balance. MVP is exactly what it stands for.

Cultural_Beyond8851 1

That is not true, at all. My SaaS product was developed after months of indepth research, many many interviews with the target market, and a lot of objection pulling. Never created an MVP, because I didn't need to. My research already showed me exactly what would sell, at what price point, and as a result we were profitable two weeks after releasing the beta product.

it is a waste of time and money to create something, see if people like it or not, and then do endless revisions. Totally unnecessary. All that can be avoided through proper due diligence.

the concept that drove most of the innovation in the 90's in Silicon Valley was driven by a book called Crossing the Chasm which talks about building a perfect solution for a small group of niche users and building from there.

[deleted] 1

What? I said it depends on what you’re doing. Congrats. I wish I could benefit from that.

crails124 2

This has been a recent thinking of mine as well. Also what matters is the quality of the MVP. If your MVP barely inches over the finish line you introduce one more hurdle in growing the business. Just as many teams should be finding product market fit, I see them spending time on fixing all the things they left behind (billing, auth, security, ops etc). Having a solid MVP will let you focus on growing the business and delivering value to the end users if it does take off.