The technical reality behind the MVP
Low tech or slightly higher tech? Options and timing costs discussed in hindsight.
In our previous startup diary newsletter, I revisited the articles from 2017 journaling my decision to build a technical MVP for my startup which was then named Metsitaba. Today I look at technology choices for a minimum viable product (MVP). The diaries I reflect on here are from 2018, a year after I committed to the MVP route and after the company name changed to Voxgig. It revisits the thinking in 2018, and gives an update on how these decisions have played out since then.
As I said at the time, “Strategic decision making in a startup is very difficult, and the best you can hope for is that your worst calls are not fatal.” I’m still writing, the company has evolved again (but more on that in coming weeks) so we know that none of the decisions I journaled were fatal. But it doesn’t mean they were all perfect!
So in 2017 I decided we’d build the minimum viable product. Next I had to decide on how and what technology stack to use. The following explores the different considerations for technical and non-technical founders. These are core strategic decisions with added strategic technology choices thrown in! So no pressure…
Technical founders: this is not a time for experimenting.
We also needed to make some practical decisions about the software engineering approach that would get us live. There are quite a few pitfalls here too. As a startup, you are expected to be innovative, and the temptation, especially if you have just left a corporate programming job, is to choose a suite of new and shiny technologies. This is dangerous.
Not only are you introducing large amounts of technical risk (does the stuff actually work?), but you are also committing large amounts of time to learning (you need to figure out all the new stuff). This is all loads of fun for the engineers, but not good for the business. Time is your most previous resource. An MVP should take no more than 3 months to launch, and you should have a “first working version” after two weeks maximum. You need to set a culture of high velocity in your company from day one.
Non-technical founders: this is not a time to pay others to experiment.
If you are not technical, and you do not have a technical co-founder, then you will be using external contractors to build your MVP. Under no circumstances should they use this an opportunity to try new things. You want an MVP built with boring, established technologies that are widespread. That way you can hire replacements easily, and you can sense-check work rates with advisors who know the tech. You have nothing to gain from “innovation” in this scenario—wait until you’ve hired a CTO to even contemplate that.
Our choices ran to the proven, established suite of tools and services we could rely on. Our system management platform was Kubernetes and we continue to run on the Google Cloud. That said, Kubernetes means we can easily move to Amazon if that becomes a better choice as AWS has Kubernetes support now. Every few years a new way of doing things becomes established, and in the current cycle, one of the key elements of building a cloud-based system is to use Kubernetes to automate everything—think of it as the NASA Control Centre in Houston for the Space Shuttle. You’d be crazy to run a cloud system without automation these days, there are too many moving parts.
To give this review some structure we need to examine each decision in terms of the strategic and tactical thinking that went into it. How did the decision further the strategic aims of the company as they were at that time? Was the tactical implementation well executed? With hindsight were the strategy and tactics as effective as we thought they would be?
Standards have risen, and even if you have a small set of features, you need decent well-designed website, and you really should have iOS and Android mobile apps if you can manage it. So you’re looking at about 3 months to pull something together. That’s three months before you get any real validation. Yes, you’ll be talking to a lot people, and doing a lot customer discovery interviews, but actual engagement with your product is a big data point that you really need.
What about our website? You need a website, and this can be a significant cost if you get one built by an agency or a freelancer. Your website does need to look professional, so what do you do? These days, things are much easier than they used to be. The first version of your website should be built using squarespace.com or wix.com. These are online website building services that provide you with ready-made templates and content, and provide basic functionality like contact forms. They are so simple and quick you’ll be up and running with a day or two. I don’t see how you can justify any more effort than this on version one of your website. Our decision to use these services was a real winner.
Eventually you will need a little more sophistication. You then face a critical decision point: do you start using WordPress? WordPress is an open-source software system that was originally a blogging platform that now has so many plugins and extensions and themes that you may never need to use any other type of technology. Sounds great! Well there’s a gotcha. You’ll move very fast in the first year, and it will be easy to find freelancers to help you build stuff, but then you’ll start suffering from technical debt.
Technical debt is the crushing complexity that builds up in a human-designed system over time. A good example: tax law. We humans are just great at adding layers and layers of complexity in ever more desperate attempts to solve problems created by the earlier layers. For a technology startup, the effect is that you get slower and slower at building new features, your site just less and less stable, and just at the point where you could be the market leader, another company comes along and executes much faster than you. You can’t keep up with feature delivery and you fall behind. You don’t make your numbers, and then the venture capitalists won’t invest. So much for ringing the bell of the New York Stock Exchange when you IPO.
But things are never that simple. Yes, a WordPress based system will incur serious technical debt over time. But, if you have no technical co-founder, then you probably should go down the WordPress route—it is the fastest way to get a real MVP live.
Since I am my own technical co-founder, I decided not to use WordPress for the first version of the system. But this decision was not without cost..
We launched our MVP two quarters after starting. Three months later than I had planned.
Some might say that’s pretty good going, but I felt pretty frustrated. WordPress would have got us there sooner. The strategic reason for this decision was that we are building a platform, and the cumulative competitive advantages of providing a platform are very significant. So we took a tactical risk: delay the MVP to build the foundations of the platform. You might think that stressing out over a timing difference of a few months is overkill, but in a startup, you only have a finite number of months before your money runs out, so every month counts. Striking a balance between higher future gains, and near-term death is a choice you face all the time.
The main thing is to talk to trusted, knowledgeable people before committing to any technical path in the early days. While a wrong decision may not be immediately fatal for a business, it can certainly drag on progress. Our next entrepreneur article will focus on technical debt, and how to deal with it if your company has created it.
You can check out our podcasts, an opportunity that grew out of our original newsletter and our MVP. We have almost 70 episodes to choose from.