You have an idea. You have drive. You have contacts. You have market sense. What you don't have is someone who can build.
So you start looking. You ask around. Someone knows someone. You see a portfolio. The person seems smart, confident, maybe they just left a job at a tech company or they're freelancing successfully. You take a coffee meeting. You talk about the vision. You feel that spark—this person gets it, they're excited, they want to do this.
Then you have "the talk" about equity. You shake hands. Maybe you even draft something on a napkin. You think: "We've got a technical co-founder. Now we can build this thing."
Six months later, you're frustrated. The code is slower than it should be. The features you promised investors aren't ready. Your co-founder is working on other projects. You're not sure if they're the right person, but now you're stuck because you gave them equity and you're not sure what you can do about it.
This is a pattern I see. Not every time. But enough times that it's worth talking about the thing nobody really teaches you: how to actually find and vet a technical co-founder.
The Problem With How People Usually Do This
Most non-technical founders approach this the same way. They look for someone who:
- Can code (check)
- Has worked at a good company (check)
- Knows the technology they want to use (check)
- Is excited about the idea (check)
And then they feel like they've done their due diligence.
But here's what they're actually checking: technical capability. And technical capability is maybe 30% of what matters in a technical co-founder.
What they're not checking:
Do they know how to ship? There's a difference between someone who can write good code and someone who can take a mess of requirements, imperfect decisions, and unclear direction and still produce something that works. Someone who can code beautifully in a controlled environment might freeze when there's ambiguity. Someone who shipped three products might be less elegant, but they'll get things done. These aren't the same skill.
Are they willing to be a founder, or do they want to be an employee? This is critical. A co-founder and a very senior developer look the same from the outside. But they make completely different decisions when money gets tight or when direction changes or when nobody's paying them on time. A co-founder thinks about the business. An employee thinks about their salary. Both are legitimate. But if you need a co-founder and you hire an employee with founder equity, you've got a problem.
Do they actually understand the problem you're solving? A lot of technical people are brilliant at solving technical problems. They're less brilliant at understanding why those problems matter to the customer. So they build technically correct solutions to problems that don't actually move the needle for the business. Then they're confused when you're frustrated because the feature is elegant but useless.
Can they communicate with non-technical people? You're going to need your technical co-founder to talk to investors, to customers, sometimes to your team members who aren't technical. If they can only communicate in technical terms or if they get impatient when things have to be explained simply, you're going to have a lot of friction.
Are they actually committed to this, or is this their backup plan? This is the one that's hardest to assess but maybe the most important. Some people are genuinely building a startup. Some people are keeping it as an option while they work a consulting gig that pays them more. These are different people. And the second type will take that consulting gig when things get hard, and you'll be left without a technical co-founder.
This is what most non-technical founders don't evaluate. So they end up with someone who can code but can't be a co-founder.
How to Actually Find the Right Person
Start with people you know or people who know people you know. I know this sounds obvious, but the reason it works is: you can ask real questions. You can call their previous manager. You can ask them about their failures, not just their successes. You can understand their actual working style, not their interview self.
Hiring from AngelList or seeing someone's impressive GitHub profile is easier, but you're operating with incomplete information. You're seeing their technical output, not whether they've actually taken a mess of a startup through uncertainty and come out the other side.
If you don't have a network yet, build it first. Go to tech meetups. Talk to developers. Understand the community. This takes longer, but it's worth it.
Look for people who have actually built something. Not "I know these technologies." I mean: you can look at something they built and actually use it. Talk to people who were in that project with them. Ask: "If we got into a disagreement about how to solve this problem, how would they respond?" Ask: "Did they ship on time?" Ask: "Did they adjust when the plan changed, or did they get stuck?"
The difference between someone who has shipped and someone who hasn't is night and day. Shipping is hard. It requires making compromises, staying motivated through boring parts, and accepting that your perfect solution might not be the solution you actually need right now.
Understand what they actually want. Have a real conversation. Not "are you interested in startups." But: "Why would you leave your current situation?" Listen for whether they want equity upside and risk, or whether they want a stable income and interesting work. Neither is wrong, but they're different people. If they want a steady income, don't force them into a co-founder role where they'll make way less money for longer.
Ask: "What would make this not worth it for you?" If they can't answer that question, they haven't thought about the risk. If they answer with something about the market opportunity or the idea, great. If they answer with something about personal life or stability, they might need salary, not equity.
Do a trial. Before you give someone co-founder equity and the title, work together on something small. A real project, even if it's not the main product. Something that takes two to four weeks.
During that time, observe:
- Do they show up consistently or do they disappear?
- Can you actually work together, or do you drive each other crazy?
- When you have conflicting ideas, can you resolve it?
- Do they ask questions about why you're building something a certain way, or do they just do what's told?
- Can they estimate? (Most technical people are bad at this, but some are less bad than others.)
- Do they communicate about delays, or do they go quiet?
This trial is worth more than any interview. You'll learn more in two weeks of actual work than in three months of conversations.
The Specific Questions to Ask
"Tell me about a project where you shipped something and you weren't happy with the result. What would you do differently?"
Why this matters: You want to know if they're thinking about iteration and improvement, or if they're just blaming external factors. Real builders think about what they could have done differently.
"Walk me through a time you disagreed with a colleague about how to approach something. What happened?"
Why this matters: You want to see if they can handle disagreement, explain their thinking, and find a compromise. If their answer is "I was right and they figured it out eventually," that's a flag.
"What's your day job right now, and how much time do you actually have for this?"
Why this matters: A lot of people will say "oh, I can dedicate weekends and evenings," but they don't really think about what that means when there's an emergency or when they're tired. If they're working full-time somewhere else, they don't have the bandwidth to be a co-founder.
"If we got this funded and suddenly you had to choose between staying with this and going back to your previous company, what would it take for you to stay?"
Why this matters: You're trying to understand their commitment level. Some people will say "nothing could make me leave this." Some will say "honestly, if the money isn't there after six months, I'd need to get a job." Both are honest answers, but they're different people.
"What's the longest project you've shipped, and what was the hardest part?"
Why this matters: You want to know if they've been through the monotonous middle, where excitement fades but the work isn't done yet. That's where a lot of startups die, and you need someone who's been through it before.
"If I told you I pitched a version of our product to a customer and they want something different than what we planned, what would be your response?"
Why this matters: You're testing whether they're flexible or rigid. You want someone who sees customer feedback as valuable information, not as a criticism of the original plan.
What to Actually Look At
Ask for more than a GitHub profile. GitHub shows you code quality. It doesn't show you much else.
Ask to talk to people who worked with them. Not their list of references. Your own network. "I'm thinking about working with this person, what's your honest assessment?" That conversation is where you'll learn something.
Look at their website or any projects they've shipped. Can you actually use them? Do they work smoothly? Are they well-designed, or are they technically correct but confusing to use? This tells you whether they understand the user side of building things.
Ask them to explain a technical decision they made in a simple way. If they can't, they might be more interested in the cleverness of the code than in the usefulness of the product.
The Thing Nobody Wants to Admit
Sometimes the person who is a very good developer is not the right technical co-founder for your startup. They might be happier as a contractor or as an employee with a good salary. And that's OK.
The technical co-founder you actually need is someone who is:
- Good enough technically (not necessarily the best developer in the city, just good enough)
- Excited about the problem you're solving
- Willing to make compromises
- Able to communicate with non-technical people
- Committed to this specific thing
- Proven that they can ship
Those aren't the same as "brilliant developer." But they're much more valuable for a startup.
I'd say maybe 20% of the technical co-founder partnerships I see work out because one side picked someone based on technical brilliance without checking the other stuff. The person could code perfectly well, but they weren't actually a founder. They were an employee with equity, and that's a different relationship.
One More Thing
Once you find the right person, you need the other conversation. The one about equity, IP, vesting, all of that. We've written about that separately, because it's complex enough to warrant its own piece.
But that conversation only works if you've already vetted the person properly. If you get the person right and the structure wrong, you can fix the structure. If you get the person wrong, no structure will save you.
Take your time on this decision. It's the second most important decision you'll make as a founder (the first is whether to build this thing at all). Getting the wrong technical co-founder costs more time and money than getting almost anything else wrong.
Have you been through this? What did you learn about what actually matters versus what you thought mattered going in?
