[MrsPeaches]

Of course there is useful insight here but it still irks me that MVP has become the word for “product with a bunch of features chopped out”.

MVPs are meant to be a business process where you try to validate your business idea as quickly as possible. It is not an actual product. [1]

I completely agree with the author in terms that an MVP should be used to test the riskiest assumptions of the work to be carried out. People seem to have forgotten about that aspect of the MVP and have instead focused on the speed aspect.

I quite like the idea of replacing MVPs with RATs (riskiest assumption test) [2] to stop the misunderstandings that come from MVP having the word “product” in it. Of course the reason for that is to focus the mind on selling from the start but it seems to have added new misunderstandings.

I may just be an old fogey complaining about what words used to mean and need to deal with the reality that language is dynamic, but it seems like it causes a whole load of issues when the important mental model goes missing.

[1] https://www.ycombinator.com/library/4Q-a-minimum-viable-prod...

[2] https://hackernoon.com/the-mvp-is-dead-long-live-the-rat-233...

[nmstoker]

"product with a bunch of [essential] features chopped off" is the most frustrating aspect of MVPs being misused.

The scenario I've seen loads with existing legacy systems is analogous having a decent but aging car, then some upstart waltzes in and pitches an MVP approach, only for the aging car to be replaced by an underpowered scooter, completely lacking boot space or whatever other essential requirement there is, but you cannot argue that this isn't acceptable "because MVP".

[xmprt]

Would you say that the MVP code should be thrown away when building the actual product?

[fcantournet]

If you built a proto as fast as possible to test hypothesis ? yes. IME it's always been a mistake to keep the MVP's codebase (and a pure catastrophy when said codebase is dumped on another team)

[pas]

Why throw it all away? If you use the bog standard components while building the MVP (and if you are bulding it as fast as you can why would you use non-standard stuff?), then you should be able to simply replace the "NotImplementedException" parts with the implementations and keep using the same codebase.

I mean, unless your MVP is a Bash script that emits a HTML page and sends an email via telnet, plus a CGI wrapper using a hand-rolled HTTP server ... why would you throw away the working and validated parts?

I mean if you use super dirty JS (Express) and jQuery ... then great, you can refactor that to use TS and plop the frontend code into components in whichever framework you like (Angular, React, Vue).

But again, these standard frameworks have a ton of "starter projects" on GitHub. Why not just start with those?

[gherkinnn]

Because chances are that in building that MVP you’ve rampaged around a domain you didn’t yet understand. And that’s fine. Expected, even.

Now your APIs are a mess. You have view details in the DB and pieces of business logic strewn across the frontend. There’s no separation of concerns because your only concern was to validate an idea. And for some unknown reason the only test you have keeps breaking because it doesn’t handle dates properly.

Previous mistakes inform future decisions. Best set it all alight.

The hardest part is understanding a problem anyway. The second try will take slightly more time but it won’t fall apart for no apparent reason.

[pas]

Rewriting the MVP immediately leads to the dangers of second system syndrome.

Fixing the obvious problems is obviously needed. But refactoring is the way instead of doing the MVP again. After all the domain is still barely understood.