In a previous article, I talked about minimum viable products or MVPs for short. I mentioned that you should look at throwing out your MVP before you release to production.

But why?

Well after going through all your minimum testable products or MTP, you conclude what features need to be in your product. This sets you up for the MVP scope but what about all the code that delivers those features, it's already there, why would I throw it away? Well in truth it's shit code, that's the point. You're iterating and getting a new test case out as quickly as possible this could be a day or a week, the shorter the better. With this in mind do you think the quality of that code could make it into production? No, if you don't know anything about code that's okay, because I'm here to tell you that no matter how good your developers are they will have taken shortcuts to get out a new test for you. After a few iterations, they will have built a feature on top of another feature and used shortcuts the whole time. Yet that's the point of an MTP, you're getting your code out as fast as possible to test an idea, that will then make it into your MVP. 

By the end of the cycle, you will have a feature set that matches what you want for your MVP, you would even call that an MVP as this is what a customer would pay for and it's the minimum work required to get there. Yet if you went through all this work to get to that MVP do you want to build on top of the shaky footing, your entire business hanging in the balance on an uneven footing that is rushed code. See the problem is many developers are stuck in ever so common "We need a prototype as fast as possible, get it done". The team will come back sometime later and say "It's done but to get the prototype to work we cut a lot of corners, you can't use it in production". Management will respond with "The customer's love, put it in production". The last sentence is a developer's worst nightmare because in the future when management wants you to build a new feature but it takes 10 times longer than it should they blame you, not the code they force you to put into production when you warned them it shouldn't be there.

Starting your business on the right foot

If you're serious about your new business don't put your MVP into production without doing a complete rewrite, you can still cut some of your code out and paste it in, but you have to do it properly, you can't just shove the whole mess into production and call it a day. It simply won't work. Well, it might work in the short term but you should be building your business for the long term. Not only will your code fall over and stop working eventually, but your developers will also hate you and you will struggle to retain them if the code base is a huge mess and doing anything takes forever.

As I mentioned the best way to fix this is to rewrite the MVP before you release it. It's still an MVP but its the feature set that customers told you they wanted, written on great foundations. That's the main point, a house needs great foundations to stay standing for years to come. Just like the house, a business requires solid foundations and in today's age, those foundations are technology. If your codebase starts poorly it's only going to get worse, if it starts solid it will be much easier to maintain, keeping it in great condition for years to come. The more people touch your codebase over the years the poorer it becomes, its the same in any business so keeping your developers also helps with the code quality.

What people don’t get
The main issue that non-technical people have when following this MTP and MVP approach is that they don't understand the underlying technology and how shortened timelines can affect the quality of the code. The quality isn't important for your MTP but when it comes to releasing that MVP it is. It's the foundation for your software for years to come, you need to get off on the right foot otherwise you will face a much more expensive uphill battle in years to come when it all has to be thrown away anyway because its a complete mess. You should still note that your MVP doesn't have to be the fastest or the prettiest thing, that's intact not what it's about. It's about delivering the core feature set for customers to start paying for, however, you need to at least set up the MVP on a solid foundation so that when you do start making changes like a facelift or faster performance you can, not only can but done easily.

Remember that once you have your MVP feature set, throw the code away and start again.