Do You Need a Technical Co-Founder?
A common advice is that startups need technical co-founders. Let's consider whether it is really the only/the best way and why it is so.
Many technology startups were started by a geek—someone capable of building the very first versions of a product. But what about people who dream of a digital product but don't have software development skills?
One of the most common pieces of advice a non-technical founder will hear during the early days is that they need to find a technical co-founder. Notably, many investors would treat that as a simple filter, one that aspiring entrepreneurs must go through before even having a shot at a possible investment.
Many famous success stories (think Google, Facebook, etc.) only strengthen this perception. Eventually, a better part of the community just repeats it without much scrutiny.
So how is it, really?
The Origins
My earliest references to the importance of technical co-founders come from Paul Graham's essays from the 2000s. While he wouldn't pack the advice explicitly into you-have-to's, the intention was clear.
As early as 2006, he wrote (emphasis mine):
A lot of those companies were started by business guys who thought the way startups worked was that you had some clever idea and then hired programmers to implement it. That's actually much harder than it sounds—almost impossibly hard in fact—because business guys can't tell which are the good programmers. They don't even get a shot at the best ones, because no one really good wants a job implementing the vision of a business guy.
It's not a surprise that Y Combinator—startup accelerator Paul Graham started—became known for, this time explicitly, repeating and amplifying the message.
It's all a bias toward the technical folks. Heck, even the discussion forum started by Y Combinator is called Hacker News.
Given Y Combinator's track record and Paul Graham's fame, it was only expected that the "you need a tech co-founder" mantra would become the go-to advice. Even more so, given that across VCs and angel investors alike, we have an overrepresentation of people with engineering degrees. Add the similarity-attraction effect to the mix, and you have a recipe for tech founder cult.
You’d get plenty of guides on how to find a technical co-founder.
A side note: I'm not trying to point a finger, saying it's all Paul Graham's fault. It's the whole ecosystem. Granted, he's been one of the most influential figures in the startup ecosystem for decades, and I know he shaped my thinking on the topic. So, consider me officially biased here.
Why a Technical Co-Founder?
One can only explain as much with clout and fame. For the perception of the importance of tech founders to take root, there had to be more.
And there is.
We can, again, start with Paul Graham (from the same 2006 essay; again, emphasis mine):
So how do you pick good programmers if you're not a programmer? I don't think there's an answer. I was about to say you'd have to find a good programmer to help you hire people. But if you can't recognize good programmers, how would you even do that?
Given that we want to build a digital product, we need developers. How would one recognize the good from the bad unless they do have technical skills themselves?
Early-stage startups have short runways. Hiring the wrong person to build the earliest versions of a product can, indeed, defeat the whole effort.
"But Pawel, we have all these AI tools these days, which help us build, well, anything!"
I know, we do. We'll get back to that in a moment. Eventually, and sooner rather than later, every digital product requires a skilled engineering team behind it. And the hiring challenge remains active.
However, there's a more prevalent consideration. Costs.
Founders famously work for peanuts. They either live off their savings or take only very moderate amounts to sustain themselves. In comparison, developers would cost way more, given notoriously high salaries in IT. Even if the compensation package includes equity, startups still pay dearly.
Hiring an agency seems even more expensive, as you have to cover the markup.
The VC logic is sound. With a technical founder, they get more for less. They build a longer runway for the companies they invest in and dodge the risk of paying an expensive engineer who might soon leave for another opportunity.
Why Not a Technical Co-Founder?
Why do we even need to discuss the matter if it is such a home run?
First of all, it's not a home run. Second, even if it were, we'd have one massive issue to address. There aren't enough technical co-founders out there.
The same rules that make the game so attractive for investors actively suck for founders. The grind of the early days is going to be painful, and the payday is far in the future and largely hypothetical. At the same time, all those lucrative opportunities dangle around, tempting to go for a lower-hanging fruit.
Signing up for a startup journey requires a specific grit and tolerance to less-than-favorable conditions. Not that many people want to do that.
Among those who do, though, many will pursue their own idea. After all, there's no shortage of good ideas. So, even fewer people are willing to join a non-technical founder as their technical counterpart.
In fact, many people with a perfect skill set for the job are also past the point in their lives when they'd consider taking it. One of my friends once wrote the following:
Co-founding isn't very appealing for people like me. The opportunity cost is huge. With our skills, we run independently or work at big tech firms, pulling 6-7 figures. Trading that for the uncertainty of an early-stage startup—with its narrow odds of a big exit after a decade of grind—isn't a winning proposition.
Unless a founding team has a technical person on board from the outset, getting one to join later is a formidable challenge. If not anything else, that itself is a good reason to consider other paths.
What About AI?
It might have been all true for a couple of decades, but now we have the capabilities to evade the tall order altogether. By turning AI into our workhorse, we can hit two birds with one stone, can’t we?
Not only do we reduce the cost of development by an order of magnitude, but we also sidestep the necessity of finding a tech founder. After all, by adopting AI, we've just made tech so much less of a core issue for the business.
Except, as for today, none of that is true.
Sure, we can generate a ton of code in an instant. It doesn't mean we can develop a product equally fast. Code does not equal product.
Yes, we can use AI to speed up software development or shorten the required research. It doesn't mean that it replaces a highly competent technical person.
In fact, because of the potentially breakneck speed of code generation, the need for a skilled developer to oversee, correct, and guide the changes is even more crucial. Remove that supervision, and any progress in product development will very soon grind to a halt.
A change in one place will create new issues in others, which is a story any developer with experience working with a really low-quality code base knows all too well.
Not to mention that keeping up with rapidly changing AI technology is a challenge in itself. We have this ongoing in our team:
- What's the best AI model for coding these days?
- In the morning, it was Claude. But let me double-check whether it’s still true.
Jokes aside, it's not only about which model would make the best suggestions. It's how they deal with data protection, how much they sustain the context, how big of a context they can comfortably chew, etc.
Vibe coding may be a neat way to do some early prototyping and validation. But once we're dealing with an actual product development effort, even if we stick with AI-powered code-generation tools, we need as much technical expertise as always.
The Third Element
It would be another argument to double down on finding a tech co-founder, even if it is hard. It is cost-effective, it promises to tame the AI, and VCs want it. What's not to love?
However, there is one more ingredient to product success—product development expertise. It's all about what drives the building effort and how we discover, experiment, and validate the ideas before spending significant time and money to make them a reality.
"But Pawel, the stories of the biggest product successes don't really mention product development. Definitely not remotely as explicitly as brilliant ideas or tech excellence. It surely means you can make it even if you disregard that part."
Sure, give a blind monkey enough darts, and it will eventually hit a bullseye.
The famous stories are a perfect example of survivorship bias. It would be much more revealing to go through the stories of randomly chosen startups from any given period. Except no one writes home about their brilliant idea that an excellent technical team couldn't turn into a money-generating machine. Well, not unless it's a big-time scandal.
If we were to judge the startup success rate relying only on published stories, we'd probably agree that 8-9 out of 10 of them succeed. In reality, we know the odds are inverted.
Remove competence in any of the three domains, and the conditions for success are not there anymore. While a non-technical founder commonly takes care of the subject matter expertise, the remaining two bases are left uncovered.
Geeks willing to join startups as tech founders don't grow on trees. Those who are both tech-savvy and have experience building multiple products are super scarce. Oh, and if we wanted to limit the options to those who succeeded with one of their previous products, we'd be looking at an empty set.
Missing Product Development Skills
What if we reverse the question? Assuming we'd like to secure both technical skills and extensive experience in building products, where would you look?
Here's a story to consider. Over more than two decades at Lunar Logic, we contributed to building more than 200 different products for our clients. Sometimes, we just helped lift some weights for the clients' teams. Other times, we did it end-to-end. Often, the products eventually failed. Some succeeded.
I can't say we've seen it all, but it's as close as it gets. As I sometimes say, our clients have paid us to fail... so you don't have to.
What's crucial in this story is not the technical skills—these days, they are mostly a commodity—it's the primary focus on product development. Every single time we work with a pre-pre-seed startup, my default advice is "build less." I am actually yet to meet a founder who would come to us with an idea for an MVP that would be minimal.
Considering such external help might be a sweet spot where we can hit two birds with one stone. There's a huge caveat to this plan, though.
VCs will quickly tell anyone who wants to listen that it's a disastrous setup for a startup. Working with an external agency/consultancy automatically means goal misalignment, which is detrimental to any collaboration. While a founder will work their butt off, the agency only wants to generate more work as they'll get more money that way.
Admittedly, VCs will be right. Mostly.
If you find a consultancy focused on development work and development work only, that may very much be the case. That would, however, defeat the purpose. After all, we started with the assumption that we'd like to find people who would cover product development at least as much as technical work.
If I were that expert, my default advice would always be "build less." I would follow up with a relentless focus on validation and agree to scale only the parts of the product that have been proven to work.
Will this approach generate less technical work? Probably. Will the effort—and money—be spent wisely? For sure. That's the difference between product developers and product developers. If you're a non-tech founder, you want the latter.
In fact, if you're a VC, you should want them, too. These folks will be around your investment (early-stage product) day in, day out, while a VC would only get a bulk update every now and then. Wouldn't having someone with this kind of mindset around a non-tech dreamer founder be advantageous?
The Right Match
The tricky part is that finding such a consultancy/agency is non-trivial. I'd be the first to admit that a huge part of this niche fits the stereotypical views perfectly. They'd happily turn scope into code for dollars and call it a day.
However, give me 30-60 minutes of talking to either of these companies, and I'm positive I'll filter out the vast majority of the bad seeds.
Anyone who would give me a straight estimate, no questions asked? Nope.
Anyone who would rather discuss specification details instead of exploring the business domain? Out.
Anyone who wouldn't suggest—heck, insist on—a smaller scope? No, not really.
Anyone who wouldn't press on some kind of discovery process? Negative.
Anyone who wouldn't be actively planning for validation? Again, no.
And I could go on and on.
It is not rocket science. You could learn all the theory from several books at most. The thing is that, in theory, knowing the theory is enough. In practice, it requires a change in the mindset. And that's hard.
Detecting the mindset is not nearly as difficult as changing it.
By the way, the exact detection mechanism would work for any candidate for a technical co-founder, too. And if, by any chance, an entrepreneur has a shot at someone technically skilled who passes it, they should absolutely go for it.
In a very likely scenario that such a person can't be found, it's a choice between a way-less-than-ideal tech co-founder and external people with the right mindset.
That dilemma has the right choice, which answers the original question: Do you need a technical co-founder?
No, not really. But for different reasons than we were told.