

When To Get Rid of Your MVP - skyfallsin
http://pradeep24.me/when-to-get-rid-of-your-mvp

======
smilliken
It's lazy thinking to decide to throw away an MVP outright. It's more sensible
to decide which pieces are fine the way they are, and which pieces need to be
refactored or rewritten, and to do so as the opportunities arise.

In particular, you're setting yourself up for failure if you're building a
product knowing that you're going to throw it away-- you'll make poor choices
that will stick with you for longer than you expect. Besides that, rewrites
are risky for a business; they are often never completed since requirements
and scope are constantly changing.

~~~
biznickman
I totally disagree with this post as well. I agree that decoupling the backend
API from the front-end makes sense from a maintenance perspective but that's
all I agree with in this article. I'd assume this is the default behavior for
most developers.

However there's no way that I'm going to build something so crappy that I want
to toss the entire thing out. I've decided to completely reprogram a system
after realizing the first approach was the wrong way to do things, but that's
different than deciding to toss your first product out the door from the get
go. I gotta agree with smilliken, you're going to write bad code if you know
it's going to be thrown out the window.

------
klaut
i think the article here confuses the MVP with the prototype. Not long ago
(couple of days if im not mistaken) there was a submission to a blog post
talking exactly about this: MVP should not mean crappy/sluggy porduct. MVP
means feature limited, not bad quality. So assuming that, one does not discard
MVP, one adds features to it. Can't find the blog post now, sadly :|

------
ropman76
I don't get this. If customers are already paying you money for something why
get rid of it? Sure there are some ugly hacks in an MVP but that is why a
start-up goes back and rewrites the ugly parts. I think Joel S summed it up in
his article "Things you should never do."
<http://www.joelonsoftware.com/articles/fog0000000069.html>

------
orthecreedence
Ehh, I'm partial to taking the time to building things right the first time.
If you build it correctly, adding new features or changing out ones users
don't like should be a lot simpler than rebuilding everything. Both the back-
end API _and_ front-end client will benefit from a thoughtfully planned
architecture.

If you build an MVP, build a really solid foundation. Take the time to do it
right. Build a _minimal set of features_ but make your foundation rock solid.
Then you don't have to waste time rebuilding when you can just add to what
you've got. Will you be two weeks later to market? Perhaps, but you can now
iterate on what you've got instead of rebuilding, which would most likely take
a lot more than two weeks.

Building things with "we're just going to throw this out newayz" in mind is
also pretty bad for morale. Everyone's smiles on the outside, but those
developing are thinking "how many rewrites is this thing going to go through?"

Building right the first time will ultimately save time, effort, stamina, and
make everyone happier with the product (customers and those building it).

------
brockf
To me, this reads as a guide of what not to do. There are two classic mistakes
suggested here: (1) Hastily build something of questionable underlying quality
because you know it will be discarded, and (2) Once you have clients, swap out
your existing platform entirely for something new and... better!

