One of the most common issues that entrepreneurs run into, that no one seems to like to talk about, is lack of a technical cofounder.
One of the most common issues that entrepreneurs run into, that no one seems to like to talk about, is the lack of a technical cofounder.
In the startup world, it is almost a bit of a taboo to mention that you don’t have anyone that can actually build out your idea. Telling someone this will often elicit from them an exasperated but sympathetic “oh…” accompanied by a glazing over of their eyes as they lose interest.
My goal here is to relieve the pain, confusion, and desperation that I so often see this issue causing entrepreneurs.
What do you do when you have a great idea and are ready to execute but there is no one on the team who can actually build the product?
You have four options.
Yes that is right, the decision can actually be distilled into four different options one of which, depending on your unique situation, will stand out as a much better choice than the others. The path you choose has far reaching consequences for the future of your company so don’t make this decision lightly. At various companies and times in my life I have experience with every single one of these options and have seen the resounding successes and devastating catastrophes that can result from each, many times over.
This option is both the best option and the most unrealistic. Finding a technical cofounder is like entering into a marriage, it is an important decision and one which a lot of the time does not work out. If you rush into a cofounder relationship out of desperation there is a high likelihood that it will not end well.
On the list of why startups fail “Not the Right Team” is the number 3 reason at 23% (https://www.cbinsights.com/research/startup-failure-reasons-top/).
A potential technical cofounder has to have a combination of high commitment, sufficient technical ability, and right cultural fit with the rest of the cofounders which is very rare to find. Often chasing a technical cofounder will result in a long period of fruitless searching after which you are back to where you started, so if you pursue this option, make sure that your budding venture can support this potentiality.
The second option is to pay a developer to code it. This option is split into two sub-options.
The first sub-option is to pay a local developer to join the team full time. This is a great option but requires money. A local developer (assuming you live in the states) usually commands a six-figure salary. Most startups that don’t have a product yet just cannot afford this.
Furthermore, without a product and traction, it is very difficult to impossible to raise enough money to cover a six figure salary. You are in a bit of a chicken and egg situation with this option where you need the money to build the product and you need the product to raise the money.
The other sub-option is to hire an overseas developer (typically somewhere in Southeast Asia or Eastern Europe) to build the mvp. This option can be affordable for most startups (https://medium.com/existek/top-it-outsourcing-countries-in-2019-772df2af7705) but comes with its own host of problems.
Typically, chief among the issues are code quality and communication barriers. Overseas developers are priced more cheaply because they tend to produce a lot buggier code and are less fluent in English than their local counterparts. These two things combined can mean you spend a chunk of money on an overseas developer and come out with something unusable that will need to be scrapped and recoded from scratch anyways.
There are some ways to mitigate these two issues. If you are fluent in the overseas developer’s native language you can mitigate the communication issues. If you rigorously filter which developers you hire and go slightly upmarket in price you can partially mitigate the code quality issues. Taken to an extreme, with these two strategies sometimes a startup can successfully have their entire dev team overseas. Usually this works best when the startup founders are from the same country as the devs, can fly overseas when necessary, and all the overseas devs work in the same office together with its own management hierarchy and are not remote (i.e. all overseas devs work together in one office in Bengaluru and are not spread out across India). This is the exception and not the most common case. More often than not, going with overseas developers wastes time and money with not much to show for it in the end.
The final option is for one of the current cofounders to learn to code. Most of the time this is going to be the answer. The strategy takes advantage of what many early stage startups have (time of the cofounders) while not requiring what many early stage startups don’t have (resources). Long term, this strategy also tends to reap the most benefits. The better you understand the technology you are using the better you can manage, understand, and filter developers. Even if you are not always going to be coding the product, it is a worthwhile investment to learn how to so that you understand the technical aspects of the product better down the line.
History supports this option as generally the best route. Google, Facebook, Airbnb, and almost all of the other unicorn startups had their founders code the mvp. In fact, it is difficult to find examples of mega-successful startups that did not follow this model.
This path comes with its own gotchas however. First, it will take a matter of months to develop the mvp and a huge time commitment. The amount of time taken to code the mvp is a function of the aptitude for learning to code of the cofounder pursuing it, the time they put in per week, and the complexity of the mvp. Tinker with these factors and you can go from having a working mvp in two months (cofounder with aptitude for coding, putting in 12 hours a day, and relatively simple mvp) to never having an mvp (cofounder has a very low aptitude for coding, won’t or can’t put in the sufficient time, or complexity of the mvp compounds a combination of low aptitude/insufficient time).
So final decision tree goes like this:
Can you afford a significant amount of time looking for a technical cofounder and abide by the possibility of not finding one or one not working out?
Then try to find a technical cofounder.
Otherwise, can you afford to pay out a six figure developer salary?
Then hire a local developer after a rigorous filtering process but keep in mind that most of the time you will be better served by learning to code it yourself.
Otherwise, do you have the technical knowledge/native bilingual proficiency to manage overseas developers?
Then possibly hire overseas developers but keep in mind that most of the time you will be better served by learning to code it yourself.
Finally, if you didn’t fulfill any of the conditions of the routes above, learn to code it yourself.
A lot of people will tell you that learning to code will take years and is a waste of time. I was told something similar by a lot of very talented technical people at well known companies. There is a lot of a gatekeeping attitude around coding unfortunately.
For someone who is intelligent and committed this is just not true. Learning to code is one of the most useful and rewarding things you can learn as a software-focused entrepreneur that will bear fruits for the rest of your career.
Note: I offer this opinion free of commercially influenced bias. I am not selling nor am associated with any product that teaches people to learn to code.