This is the second part of a three-part series on our technology choices. We're nearly a year in business so it makes sense to pause and reflect on our technical decisions. Strategic decision-making in a startup is very difficult, and the best you can hope for is that your worst calls are not fatal.
In part one I discussed our decisions up the end of 2017. Let's now look at the first quarter of this year.
On January 1 2018 the sum total of our 'technology', such as it was, was a newsletter supported by some ad hoc tooling, a cookie-cutter website built using an online website builder, and my previously published work in the open-source software community.
The next step was to build a minimum viable product (MVP). If you go back to the articles written at that time (available online on our blog or independent.ie) you can get an insight into the practical approach that we took.
But lets go up a level. Was building an MVP the right approach? Could we have taken another path?
One alternative is go into what is known as 'stealth mode'. You have this option when you have funding for about two years (which we do), and you can thus afford to hide yourselves away in a dark room building fabulous software.
This is an extremely high-risk strategy as you are wholly dependent on your own domain knowledge. It can work if you really know an industry, are solving a clear pain point, and have relationships that you can use to make sales later on.
A good example would be when you can solve a problem deep inside a large industrial supply chain, say in pharmaceuticals or telecommunications infrastructure. Another would be when you have identified a structural inefficiency in a sector that is dominated by a few large players - airline bookings say. In stealth mode you avoid all publicity and do no marketing until you are ready to launch.
From our perspective in voxgig, where we are trying to build a community-based business, and where deep features are not our chosen competitive advantage, stealth mode does not make much sense. Yes, our competitors know what we are up to, but then our chosen industry, business events and conferences, is so fragmented and has so many competitors, that it does not really matter.
Since our marketing strategy is to generate network effects through community building, we need to be "out there" from day one. Given the success of our newsletter, community events, and our subsequent ability to close initial trial clients, I think we can conclusively say that stealth mode would have been the wrong decision.
But just because you're not in stealth mode doesn't mean you have to build an MVP. There is also another viable path that could have worked for us: consulting-led product development. In this model, you first look to close deals with a few early customers to build solutions specifically for them. You then convert these custom solutions into a product. This is pretty hard, both technically and commercially, but it can be done. Perhaps one of the best examples is the German software giant SAP, which did exactly this - Hasso Plattner and Dietmer Hopp were IBM engineers who decided to found a consulting company in the late 1970s after their AI project in IBM was shelved (AI follows a boom and bust cycle - we're in a boom now - you're been warned). Their key innovation was to move away from punch cards to 'real-time' processing using programs and data stored in active memory (fun fact: the 'R' in SAP's former flagship enterprise product line, R/3, stands for "real-time"). Plattner and Hopp's first project was an accounting system for the chemical company ICI.
The consulting-first strategy is attractive because it provides you with early revenue that can self-fund your product development. You need to find one or two really big clients that will sign multi-year deals that will pay for a team that is big enough to both support the clients and build a product-at least 10 engineers as a rule of thumb. So you don't need to pitch for funding, you are profitable from day one, and you get to develop and validate your product in a real-world scenario. What's not to like?
Consulting-first is much harder than it looks. We tried to execute this approach in my last company, nearForm, and eventually reached the conclusion that while we were an excellent consulting company, we did not have product DNA.
They really are two very different mentalities. The problem with winning a fantastic large client that desperately needs your skills is that they have an insatiable appetite. It becomes very hard to justify the lost revenue from assigning all engineers to the client and billing them out at eye-watering day rates. Internally, those focused on client work feel unloved compared to the 'special' people working on product. I've yet to find a solution to either of these problems other than accepting the near-impossibility of making it work and deciding instead to focus on either consulting or product. It is possible to do both, but it is beyond my management abilities.
Knowing and recognising your limits is also an important part of being a founding CEO, so I knew we could not execute on this approach, despite its monetary advantages. That decision still feels right.
As an aside, if you are thinking of doing a startup, I would recommend thinking seriously about running a consulting company for a few years first. You'll gain a lot of valuable business experience, and you'll earn a decent living. The reality of sleeping on other people's sofas and surviving on fast food is not quite as glorious as all that.
So we return to our MVP strategy. Having decided to build one, which is the core strategic technology choice, 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 three 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.
How do you balance these constraints? 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 advisers 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.
If you do have a technical co-founder, or you are one yourself, you have a little more freedom, but you still have to act in a very restrained manner. This is our situation in voxgig. We have taken on one key element of technical risk. Our MVP is a search engine for conferences and speakers. We decided to use a newly open-sourced machine-learning search engine called vespa.ai as our search solution. The standard industry solution is to use an established open source technology called ElasticSearch.
However we are planning to use machine learning based on our data in future so it makes sense to validate a platform for doing so. Vespa.ai provides a plug-and-play search capability and gives us a little bit of future-proofing. It has been used by Yahoo as a proprietary system for eight years, so we know it works at scale in production. It does not have a big community (yet), which is the major risk for us.
Everything else that we use is proven and established. Our system management platform is Kubernetes and we run on the Google Cloud. That said, Kubernetes means we can easily move to Amazon if that becomes a better choice - Amazon just announced Kubernetes support.
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.
Next week, the importance of a software platform for your business.
(Newsletter update: 2,742 subscribers, open rate 11pc)