How to not have to rewrite your MVP from scratch

Posted by Bogdan on Jul 31, 2015 1:54:00 PM

10_watering-can-660x495People in startup circles love the concept of MVP (Minimum/Minimal Viable Product) and for good reason. The purpose of the MVP is to demonstrate the core features of your concept and validate your business idea. Specifically giving you the required opportunity to test your product market fit assumptions. Building a MVP should be cheaper, faster than trying to build a ready to hit the market product.

Here’s the typical scenario that an entrepreneur faces:

  • Entrepreneur comes up with an idea
  • Entrepreneur finds a technical team that is interested in bringing the idea to life (either for money, equity or both)
  • Entrepreneur + the team discuss the challenges in building the MVP
  • The team  iterates and delivers the MVP
  • Entrepreneur starts presenting the MVP to people and validating the idea, the market etc.

This is a typical scenario, inspired by the lean startup methodology. It’s interesting to watch what happens between the MVP stage and the product stage. Things like choices you’ve made in your MVP stage can affect the timeline of your product. A very common occurrence is to rewrite everything from scratch, maybe even using a different language, a different team or a different product design philosophy. Here are a few tips that can help you get the most out of your MVP, and avoid a total moth balling.

Check what are the most loved technologies in the community

Depending on the nature of your product you’ll find different technologies that the community love and support the most. If your product is a data science/analytics product you should consider choosing R or Python. If your product is more IoT oriented, have a look at Node or Java. Research the communities first, talk to people inside and then decide. If you’ll choose C++ for developing a web related product you’ll probably have problems finding developers later on. I recommend staying away from cobol however seductive it may seem.

Adopt new and exciting technology

Some people would disagree with this because the newest technology might not be the most stable one. This might be true but cutting edge technology has the advantage of attracting talent. Developers will want to work with you just so that they can use the technology they love. Trust their decisions and don’t be scared of using new tools. Remember, you’re only as good as the tools you use!  With the power of GitHub you can validate the stability of the technology very easily.  

Test religiously

This cannot be understated. Having a good automated testing framework is very important. At this point you won’t have hundreds of people using your product or a QA team. To be sure your product doesn’t degrade along the development process you’ll need to have a lot of tests in place. Degraded quality is one of the most frequent reasons for rewriting your MVP completely.  It is so much easier to detect redundant or useless code when you have an all inclusive automated testing model. That being said, don’t be freaked out if the bugs are piling up. Treat them as a necessary evil in exchange for your agility, fix them and move on.

Be lean, not cheap. Use 3rd party tools and libraries

Don’t attempt to implement your marketing automation or customer support system yourself. There are a lot of affordable or reasonably priced tools out there that offer much more than you can possibly implement yourself. Some of my favourite tools are: intercom.iohubspotpipedrivezendeskwordpresszapier and there are many others. This is the time to focus on your core product and not on features that other do very well.  Stay as focused on your delivery as possible. You can always replace them with you custom stuff when you have free cycles, if it makes sense.

On the same idea, use community developed libraries that best fit your needs. These have the advantage of usually being battle tested, maintained and continuously updated. Choose frameworks with easy to install plugins and apps. Some very good frameworks with a lot of community plugins are Django and Rails.  Just keep an eye on the license types, and as you are about to go to market, talk with your local accelerator about your licensing risks.

Core functions over bells and whistles

I get it, sometimes a sexy little feature has immense selling power.  However an MVP is about the core functionality not the bells and whistles.  Avoid spending time on the bells and whistles including, over designing, animations, funky graphics.  Think foundation, skeleton, and framework.

The bells and whistles will probably need to be re-written.  Actually they WILL need to be re-written.  So focus on the core functions.  Think flexibility and extensibility.  When you are pitching a product concept, if people care how it looks, they are the wrong people to pitch to.  


  1. Use new and popular software. You’ll get less headaches and more enthusiastic techies.
  2. Continuously test your product. Getting to a point where the bugs become unmanageable is not acceptable.
  3. Focus on your product and not on details like marketing automation or customer support. There are a lot of tools that can help you with these or other similar problems
  4. Finally, core differentiating technologies will survive past MVP stage far longer than little bells and whistles.

Topics: Team, Startup, MVP