Software - don't build it until you know that they will come
The voxgig founder gives a how-to on the essential tools that need to be used by new ventures to get their ideas out into the world in front of investors
This is the diary of a technology startup, but I have been remiss in not discussing technology for the last few weeks. What has been happening on the software front since our soft-launch in March?
The question of how to get your software built is a very pressing one for many startups. I'm a technical adviser to a number of Dublin-based startups and this really is one of the biggest challenges that they face. It also comes up in many casual conversations that I have with other founders.
My first and strongest advice is always: don't build anything. That applies even if you have a technical co-founder. In the early days, it is far more critical to validate your business idea and the market need, than it is to worry about writing any code. This is the approach that I took, despite being a software developer by trade. In my first startup I made the mistake of hiding in a room writing code for the first six months, and launching a product no-one wanted.
Instead of writing code, use the many online tools that are available these days to validate your idea. You can build a website quickly with wix.com or squarespace.com. You can get a little more sophisticated with WordPress.com - and you can find lots of freelance web developers to help you add a few extra pieces of prototype functionality to WordPress. It may be a blogging platform, but there are plugins for everything.
If you are a technical co-founder, your job at this point is just to build that website. I built the first version of the voxgig.com website using squarespace, and we still use WordPress for most of our static content.
If you want to get fancy, you can also use "landing page" generators like launchrock.com. If you really, really want to build a few custom features, then look at online app generators like bubble.is or airtable.com. If you're writing any code in the first three months, you're doing it wrong.
That's where you start. But what happens afterwards, when you have validated that there is a potential market, and you do think you can now build something special? How do you go about it? And if you're a non-technical CEO, how do you manage the development side of the organisation? This is where you have to take a strong position on your duties as CEO. Just as you must understand basic accounting (cash flow, profit and loss, and balance sheet), your basic marketing (positioning, pricing, channels, etc), your sales process (lead generation, value proposition, pipeline management, etc), and HR (employment law, contracts, recruiting, etc), you must also have a firm grasp on how your technology works and is built. You don't get a pass by hiring an outside contractor, and you don't get a pass by having a technical co-founder.
You can't be Henry Ford if you don't obsess about your factory and its production line.
There's a trap here that you need to avoid - "bike-shedding". Imagine you're on the committee to approve the design of a nuclear power station. Said committee includes many stakeholders, most of them non-technical. The design of the secondary coolant system is quickly approved after a presentation from the lead engineer that seems plausible but that nobody really understands. The next item on the agenda concerns your efforts to appear "green" by promoting a cycle-to-work scheme. What colour shall we paint the bike shed?
As everybody understands this question, a great deal of discussion ensues, and reaching agreement takes the rest of the morning. Total time discussing the secondary coolant system: 45 minutes. Total time discussing the bike shed: three hours.
For software startups, substitute data model and workflows for the coolant system, and colour scheme and logo for the bike shed. You have limited time - spend it wisely. Some things have a much greater impact on success. You can always hire a professional designer to get a great user experience, but only you understand the business problem that you are trying to solve, and that reveals itself in the design of your data model flows. Nobody said this was going to be easy.
There are three things you need to understand and ensure as CEO when it comes to technical production. They all involve strategic choices, expenditure and resource trade-offs, so they fall squarely within your responsibilities.
First, you need to worry about source code. The source code is the heart and soul of your system, your primary intellectual property, and the thing you're going to spend a lot of your funding on. Getting your team to produce code that moves the business forward is one of your biggest management challenges.
A mistake I often see is to assume the technical team members are like architects or kitchen fitters. Aren't they professionals and can't they just get the job done on time? No, and no. Computer science is a young discipline, and us coders still haven't figured out the right way to build things. Come back to us in another 50 years or so and we might even have professional accreditations. For now, accept the reality that building software is a high-risk, very hard to measure, and unpredictable activity.
Given this reality, you need to put some active management in place. Your team absolutely must use "source control". These days, that means storing your source code on github.com, gitlab.com, or equivalent. These sites might seem intimidating if you are non-technical, but dig a little deeper and you'll see they provide blow-by-blow auditing of your software team's technical delivery. If you're not using source control, you are not a serious contender.
As a startup, you need to be using agile practices. Ignore the consultants. To be agile just means that your team is delivering software on a weekly basis. By deliver, I mean "going live". Each week you need to be delivering new functionality to the production system. This is vital. If you allow a situation to develop where the team is building to a deadline at some point in the future, then you are not going to hit that deadline with good quality software. Further, you won't have the ability to respond quickly to customer feedback - and that's the key to moving quickly and capturing market share.
Does voxgig practice this? You may have noticed that our live site, voxgig.com, has not changed much since our soft-launch. We're running a small number of private trials with a group of early adopters. This lets us refine the feature set so that it matches what customers need much more closely than our initial guesses. We've taken the strategic view that it's better to hold-off on public registrations until we're confident that our system is useful. This strategy may not be right for you - that depends on your product and how it fits into the needs of your customers. Our software helps to run events which means that it is used very intensely for short periods of time, during which it absolutely must work, and work well.
Second, you have to decide where to host your system. There are really only three options these days: Google, Amazon and Microsoft. These behemoths provide so much supporting infrastructure that you'll have a hard time justifying a "build-it-yourself" approach. Yes, this will eat into your cash, but you should not compare cloud costs of the big three to other smaller vendors. Instead compare them to the cost of developer time, which is much more expensive.
I will also make a specific technical recommendation: Kubernetes. This is a vendor-agnostic technical tool to manage cloud systems (don't worry, it's free and open source). It's complex, and if you haven't used it before, you can expect to spend some weeks getting up to speed. It is fast becoming the "standard" for cloud system management, so you shouldn't have too much trouble finding people who know it, or want to learn it. You can expect to put several weeks into Kubernetes before it starts working for you, but the trade-off is well worth it. It makes it much easier to deliver on an agile basis, much easier to scale up once all those lovely customers start flooding in, and much easier to move to a different cloud if you need to.
Third, you have to roll up your sleeves and manage the project. A technical project does not manage itself, and takes far more effort than you think. I've written previously in this series about our number one technique for keeping things on track: the weekly demo meeting.
Every Monday the entire voxgig team gets together on a video call. Team members that have built something in the last week (and not just technical stuff) give a little demo of their work. This is wonderful for accountability - you know you'll be showing your work to your peers. It also keeps the whole company up to speed on each other's work.
There is one critical rule: to avoid bike-shedding and political grandstanding, no discussion is allowed. Feedback is captured elsewhere, and in written form. You have to sit still, listen and observe. This is really hard if you're a founder. You just to have to let people give demos on their own terms even if they've built the wrong thing. By doing this, you create a safe space for maximal information sharing, and that keeps your development velocity high.
I won't recommend a specific project management tool - they are all equally bad! But you do need one, and you do need to use it rigorously. There's just far too much going on to keep track of things with pencil and paper, or even whiteboards.
There's a lot more to technical delivery, and we'll return to this topic in future articles. The first step to understand as a founder is that you can't outsource the management details. As with all other areas of the business, you need to understand just enough to be dangerous!
Newsletter statistics for this week: 2,224 subscribers and a 17pc open rate. Not bad given all the GDPR noise. Of course, it helps if you're producing useful community focused content - that's always the best marketing.