I recently read a tweet from Milktea that expressed uncertainty on how to scale Minimal Viable Products (MVPs) past the proof of concept stage. It made me think about how I had developed applications in the past, and reflect on common patterns I had employed. Given her occupation I suspect she was talking about the design of a product, but seeing as Iâm a programmer this post will lean more towards the code side of things.
My Background
First, a bit about my experience. Throughout my college career, I participated in various coding challenges. I attended two startup weekends (placing 3rd at one of them), a Microsoft hackathon (placing 3rd), a MindBody hackathon (placing 1st), and a Global Game Jam (placing 1st). There were several smaller events I competed in as well, but these are the ones I consider most memorable.
Itâs also worth mentioning that I attended an Entrepreneurship class that went into MVP theory during my senior year; while I wonât be getting into that class as much in this post, the big takeaway was âmake small, quick iterations and pivot frequentlyâ. In essence, build a small feature, try it as soon as you can, and respond to feedback accordingly.
Patterns and Shortcuts
These are some of the concepts I feel are important when developing an MVP. They include some shortcuts Iâve found helpful when Iâm under time constraints; If you arenât severely pressed for time, then some of these sections (such as edge cases and unit tests) wonât apply.
Iâll go into how to scale an MVP at the end of the post, but these help establish some context.
Domain Knowledge
You want to be aware of whatâs going on in your field. This doesnât mean you have to be an expert; just be knowledgable on what tools people are using and what trends are popular. I use Twitter, RSS Feeds, Email Newsletters, and GitHub to stay on top of emerging web frameworks and libraries. When it comes time to make an MVP, having a large list of third party scripts and plugins is immensely useful. I might not know how to code an autocomplete system â but I do know two or three open-source libraries that will do that for me. Iâve published my list of bookmarks before. While itâs slightly out of date at the moment, anytime I need to implement a feature on an MVP Iâll check the list first to see if I have a resource that does some heavy lifting for me.
Start Small
Beware of feature creep. Figure out what youâre going to do, and then think about how necessary each feature is. Is it something that can be added after you launch? Is it something thatâs truly worth having when you go live? Stay as focused on the core components as you can.
Heavy use of Plugins
Also known as âDonât Reinvent the Wheelâ. If you donât have to code something yourself, you shouldnât. In most of the MVPs Iâve made, code I custom write generally is more of a glue than a system. I choose several existing libraries, and spend a bit of time stringing them together.
Normally, you wouldnât want to do this. A website should be lean: plugins add a lot of cruft and bulk. But when youâre on a budget (especially when it comes to time) plugins and libraries like jQuery are your best friend. If a script does X, Y, and Z but you just need a script that does X, use it! The Y and Z features might add page weight and be annoying down the road, but for an MVP you just need to get a system that you can demo. Try to offload as much as you possibly can to third party libraries and plugins.
Contained Custom Components
When you need to develop something yourself, make it contained. Chances are, especially in the rush to present an MVP, your initial implementation wonât be as flexible or robust as youâll need it to be later. You want to make it as cheap as possible to go back, rip it out, and swap in the new system. Think Iron Man and his Arc Reactor â when one dies, he pulls it out of his chest and puts a new model in. So instead of calling an API everywhere in your code, make a wrapper class that is the only place where you directly interface with the API. It will be far less painful in the future if you need to switch providers or make a fix.
Donât Unit Test an MVP
Unit Tests are good if you have a product that is going to be long-term and stable. MVPs are meant to be agile in spirit; youâre going to be making a lot of changes frequently. Wasting time writing tests for a feature which might not be there next week just isnât worth it. An MVP should also be fairly small; manually testing it should be less time consuming than writing unit tests.
Ignore Edge Cases
This one can bite you. In both of the startup weekends I attended, our MVP crashed because of programming errors that were the result of ignored edge cases. Ultimately, the time you save by ignoring these is worth it though. Focus exclusively on the main use case.
So⊠How to Scale?
Finally, letâs return to the question at hand! How do you take an MVP and scale it to a finalized product? My answer: use the same MVP process, but also revisit history to correct previous shortcuts. Generally after a launch Iâll spend a lot of time addressing some of the bigger pain points (things like optimizations, tests, and edge cases) before I start on new features.
In my experience, an MVP and an âupgraded MVPâ can be viewed pretty much the same way. Iâve never seen a product that is âdoneâ before. Usually, thereâs something that needs tweaking, some new technology that can be added, some new design you can use. The same attitude that you had for your MVP can â and should â be applied to new features going forward. For instance, instead of adding social integrations all at once, break it into parts. Start with share buttons, then add Twitter card support. Break new features into smaller, contained MVPs.
As your product expands, problems will arise caused by things that you thought were fine. Pivot! Identifying these areas during your initial MVP phase isnât always possible â donât spend a lot of time worrying about it. Experience will also help here; the more MVPs you ship, the more aware of potential problems youâll be without spending a lot of time beforehand thinking about implementation details.
Conclusion
My professor told me once that it takes less time to fix mistakes than it does sitting around thinking about how to avoid mistakes altogether. I think in an industry where you can ship updates quickly and cheaply, itâs advice worth taking to heart. Ship fast and break things â learn from experience!