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.<p>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.
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 :|
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."
<a href="http://www.joelonsoftware.com/articles/fog0000000069.html" rel="nofollow">http://www.joelonsoftware.com/articles/fog0000000069.html</a>
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 <i>and</i> front-end client will benefit from a thoughtfully planned architecture.<p>If you build an MVP, build a really solid foundation. Take the time to do it right. Build a <i>minimal set of features</i> 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.<p>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?"<p>Building right the first time will ultimately save time, effort, stamina, and make everyone happier with the product (customers and those building it).
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!