Do I need a technical co-founder? is not the right question

DALL-E2

Startups are mostly innovation-led. Technology brings magnitudinal benefits (speed, cost reductions, efficacy, etc.). And in the digital domain the ability to break free of traditional business constraints (e.g. geography, human hours, material inputs, etc.). So technological innovation is fundamental to the startup game.

The world’s most renowned accelerator Y Combinator (YC) became known for promoting the idea that a startup must have a technical co-founder. They have since relaxed this as a requirement but still recommend it. And most startup investors look favourably upon startups with a technical co-founder.

There are good reasons for this:

• A testable Minimal Viable Product (MVP) needs to be built and rapidly iterated upon.
• Outsourcing development is costly, slow, and the technical knowledge is not retained within the startup.
• Unproven founders do not have the credibility to raise enough funds to hire expensive in-house developers.

But the issue is not actually about having a technical co-founder — it is about having enough technical capacity.

Michael Seibel, YC CEO, advises startup founders never to be in a position where they need permission to proceed. If necessary funding cannot be raised, then he bluntly recommends changing the idea. This might sound brutal but he is definitely being cruel-to-be-kind. The bottleneck for most startups is development ability. Business hustle is also critical but can be done with passion and energy. But if you cannot code, you cannot code. Likewise with product prototyping or deep tech science.

Different approaches to securing technical capacity

So what are the options for being able to found a startup without a technical co-founder (be that a coder, product designer, or deep tech researcher):

1. You are sufficiently technical yourself to work through the initial MVP iterations.
2. You are working on a solution that can reach customer/product fit without the need for expert technical development.
3. You have a track record sufficient to raise the funds to engage technical partners/employees. This requires having previous startup success or being a renowned expert.
4. You are independently wealthy or have wealthy friends or family members who believe in you.

Let us look at each of these options:

1. Build it yourself: This is a personal judgement call as to whether you have or can learn the necessary technical skills. Time is a factor. Startups should iterate rapidly. This is to take advantage of customer feedback (and goodwill), while also keeping ahead of the competition. If you are initially building a solution for yourself there can be a little more leeway regarding development speed.

Build it yourself example: The founder of Supermetrics, Mikael Thuneberg, had the job of manually manipulating marketing campaign information. To save time he started teaching himself ways to automate the data aggregating. One of his first breakthroughs was to connect the Google Analytics API to Excel. He then gradually expanded his coding skills over the years. Initially, he was solving his own problems and it was a few years before he even took on an employee. Supermetrics now serves over 750,000 users globally.

2. No-code MVPs: No-code should be the starting point for exploring any digital MVP solutions. The classic tools for no-code solutions are spreadsheets, online forms, websites/ecommerce/peer-to-peer marketplace platforms (e.g. Squarespace, Shopify, Sharetribe, etc.). And now there are new kinds of dedicated no-code platforms (e.g. Airtable).

There are many regional no-code successes but it is hard to find a global success that started out with a no-code MVP.

Multi-national startups usually grow rapidly by solving hard technical challenges — initially for small markets— that gives them a window of monopolistic opportunity. This is often combined with aggressive territorial expansion. No-code solutions can be easily copied and are therefore hard to defend and scale globally.

Also if you are making a consumer-facing MVP it is no longer enough to have some basic functionality. Just having barebones functionality was the original idea of an MVP. That might still be possible in some B2B or niche situations but in the general world of consumer solutions, the overall expectations are high. So the onboarding and user experience (UX) also need to be top-notch otherwise remote users will abandon a trial even before they get to test the functionality.

Side note: The V for viable in MVP always applies. In every case, you are creating the minimal viable product that can validate a specified value hypothesis. If having a beautiful UX wrapping is required to get people to test a function then that needs to be part of the MVP.

Another drawback of the no-code approach is the lack of technological defensibility. This is of course a concern for VCs as well.

No-code example: A fellow Kiuas 2019 cohort startup Gubbe was able to prove product/customer fit in the early days by managing the student and elderly support matching via spreadsheets. They have now built a digital platform and expanded into Sweden. There is inevitably considerable competition in other regions of the world.

3. You are not renowned: You cannot build it yourself, there is no option for a no-code MVP, and you are not renowned (at least not enough). Then you should explore another solution or problem area. No matter how great your idea could be if you can’t get it validated why set yourself up for failure?

4. Independent wealth or wealthy friends: Try to avoid this option unless you, your friends or your family are exceptionally wealthy. Often you see highly successful founders, with plenty of money to fund MVPs themselves, still raising funding from others. This is simply smart as it forces them to jump through some provisional validation steps.

The challenge with points 3 and 4 is that it is often hard to evaluate if a founder has enough renown or social capital to secure sufficient funding to cover the technical capacity. Sometimes it cannot be known until the startup team is bounced against harsh reality.

One of the greatest dangers related to this is being partially renowned—as you can get funds but not enough to cover the true costs. Keep in mind the Startup Rule of Pi: everything takes 3.14x longer than planned, costs 3.14x more than budgeted, and makes 3.14x less than anticipated. So what happens is that partially renowned founders can get enough to make an MVP and do a few iterations. But if they do not hit the mark on this first leg of the race (most likely), they will not have enough runway to pivot. It is then hard to raise funds on the back of a failing MVP than when the dream is still fresh.

Side note: For unproven founders, it is advisable to take as much funding as you can upfront. Do not rely on additional funding down the road.

Have unproven, solo, non-technical founders gone on to make successful startups?

This Techcrunch article highlights that many solo founders do succeed but it does not indicate how many of them are technical. The two YC founders it highlights as case studies, Pebble’s Eric Migicovsky and Dropbox’ Drew Houston, were both technical in the beginning.

The first iteration of Twitter was partly outsourced while Jack Dorsey was working on the podcasting service (Odeo). However, Dorsey (himself a coder) brought the prototype to the Odeo co-founders who were able to use their resources and expertise to help turn the concept into a successful and scalable product. The Odeo co-founders were already highly credible: e.g. Evan (Ev) Williams had co-founded Blogger (acquired by Google).

Neither of the Swappie co-founders, Sami Marttinen and Jiri Heinonen, have technical backgrounds, however, they were able to secure the right level of technical capacity to validate their idea. Break-out successes such as Swappie are the reason why smart investors don’t rule out startups based on business model innovations rather than technology-led ones. But they are relatively rare.

Try to find solo non-technical (as yet unproven) founders who created successful startups without technical co-founders. It is really hard. Remember fashion design/prototyping skills are also technical (e.g. founders of LuluLemon, Spanx, etc.). as are skills like making great smoothie prototypes (e.g. Innocent Drinks).

The technical capacity issue is more intensely related to founding startups — as compared to newly-started (SME) businesses.

The technical capacity issue is strongly related to the context of startups. And it is therefore important to understand the difference between a startup and a newly-started (SME) business.

If we are going to attempt to clarify the difference, where better to start than by looking at startup definitions as prescribed by some of the most highly regarded startup experts?

Paul Graham and Steve Blank differentiate a startup in terms of innovation, speed, and scalability. Newly-started SMEs usually riff off proven business models and their growth tends to be gradual. A startup, however, aims to achieve rapid and exponential growth mainly through technological innovation. This is because technology enables a startup to break through existing growth constraints (e.g. geographical reach, hourly billing, material resources, etc). Or enable “10 times” magnitudinal benefits in at least one core dimension (speed, cost, efficacy, etc.)

If a startup can validate technological feasibility, market demand, and growth channels then it is expected to grow exponentially. This justifies the upfront risk investment required to see it through the loss-making validation stages. The potential for exponential growth comes with an inevitable corresponding increase in risk. From an early-stage investor perspective, this accounts for the 80%+ failure rate.

Side note: From the lifetime of a startup POV the failure rate is more like 95%+. But early-stage investors can cash out before a later-stage failure. The further up the food chain the less chance of failure; but the returns correspondingly diminish.

Great global businesses have been built for millennia. The term “startup”, however, only became widespread in the 1970s and 1980s in relation to the technology industry boom in Silicon Valley. Startup ecosystems commonly consist of close connections between startups, universities, and investors.

The relationship between Stanford University and Sandhill Road venture capital (VC) firms is a startup ecosystem progenitor. The university provides a growth bed for innovation. Students (and alumni) provide energetic and audacious talent. Investors provide funds for validating product/market fit and fuelling rapid growth.

Twists on established (i.e. already proven) business models are not startups. There is a grey area when it comes to the ability to scale rapidly across multiple regions with investment funding power. But in this context the ability to scale still applies.

Until a startup has a proven scalable model, it is (in essence) a financial research project trying to validate a scalable business model. The dynamics between startups and newly-started SMEs are therefore significantly different. On the surface, they share many business function similarities and this is what can cause confusion.

Professor Bill Aulet of MIT outlines the difference by differentiating between SME Entrepreneurship and Innovation Driven Entrepreneurship (IDE). While it is good to highlight the point that both come under the umbrella of entrepreneurship, the term IDE is not in common usage and is essentially what startups are. The following chart is helpful to highlight the differences.

Avoid these technical capacity pitfalls.

A fellow partner in the communications agency I co-founded sometimes told clients they paid him to help avoid all the mistakes he had made in the past. So here are some of my miscalculations related to technical capacity — but for free 😀.

My startup Pricetap requires our brand customers to put the solution in front of their own customers, so it needs to be a positive digital experience. Their customers, who are used to high levels of global excellence, will not want to test a digital solution that looks and feels half-baked. They will abandon a trial even before they get to the core features. So this requires a fairly high level of development expertise. I knew this in advance. What I underestimated was the costs of iterating and the high probability of the need to pivot.

The Pricetap founding team has a high level of technical skill: one of Finland’s most highly regarded iOS developers and a globally experienced UX/UI designer. Both have been willing to carry a lot of sweat equity risk. But I failed to secure enough full-stack coding capacity.

I had been unable to persuade previous technical co-founders and technical friends (now married with kids) to forgo their high salaries and join me. I am not a newcomer to this game, so I was still able to raise some funding from some wonderful angels and Business Finland. But nowhere near enough to hire an experienced full-stack developer.

I was able to engage a student coder and supplemented their lack of experience with some code-paring via a deal with a boutique coding company whom I knew well. This was via a good deal but still expensive. This “solution” kept the core knowledge mostly internal and we managed to make a sweet MVP and go through a few trial-based iterations. But the setup had a major flaw — it was relatively slow. The student had always been clear that their priority was their university studies. So our overall ability to react to the few and hardwon trial learnings was not fast enough.

The crunch came when we realised we needed to make a major pivot. We had a new trial agreement in place but it required a fairly substantial amount of work. And by this time we had essentially lost our student coder to their civil service duties and now their master’s thesis (although he continues with maintenance). And we have no more funding left for external coding. In addition, we lost that trial window of opportunity and no doubt a drop in credibility.

Learning: Not only do you need the necessary technical capacity to make and iterate on an MVP, but it also needs to be fully committed in order to react fast enough.

I blame my own hubris and wishful thinking for this situation and would happily write a glowing recommendation for the student coder. I have no doubts he will have a stellar career (his thesis is on AI’s ability to read emotions in MRI brain scans — a spinoff of his civil society work at Helsinki University). And my initial customer discovery work could have been done better based on the knowledge I have subsequently gained. This could have made the trials more efficient.

Sidenote: Our team is still open to a full-stack partner willing to put in a whole load of sweat-equity work. Please do ping me if you can recommend anyone.

Occam’s razor reality regarding technical capacity

The top early-stage VCs look to invest in startups that have the potential to be billion-dollar businesses. Without a technical innovation that enables magnitudinal benefits, or a solution that can expand easily across borders, unhindered by human hours and material constraints, the chance of that happening is very small. And if it does happen it would be well beyond the common ten-year lifespan of the average VC fund.

In the case of unproven founders, a healthy startup should contain a business hustler and the necessary technical capacity (usually a technical co-founder). But what if you had to choose between a) a business hustler without MVP-level technical skills, or b) a technical developer with some business skills? The answer should be b — as, without a working MVP that can be rapidly iterated upon, it is not possible to prove product/customer fit no matter how good the business skills are.

Therefore ensuring technical capacity is critical: be it via one’s own skills, a technical co-founder, or abundant funding accessed via personal renown.