To vet a technical co-founder without reading their code, check what you can observe (how they work with you on a real deliverable, how they handle disagreement, what past partners say) and pay an outsider to judge what you can't. Then make the equity earn-in contractual. This guide starts after you've settled whether a technical co-founder is the right answer at all and are looking at a specific person. It sits within our Startup CTO guides: leadership, diligence and the first hires.
Why does vetting a co-founder differ from vetting a hire?
A hire can be managed out. A co-founder holds a stake in the cap table and a voice in governance, and neither goes away when the working relationship sours. Y Combinator's Michael Seibel puts the purpose of vesting plainly: if you fear what will happen if you have to break up with a co-founder, make sure you have a proper vesting schedule.
That changes the order of operations. With an employee, you assess, hire, and adjust. With a co-founder, you trial first and grant equity after. The steps below are four checks (working behaviour, outside technical judgment, disagreement, past partnerships) followed by the paperwork that makes the result binding.
We don't cover how much equity to offer here. Sources disagree, and the number matters less than whether it's earned over time.
How to vet a technical co-founder in six steps
1. Start with people who can vouch for them
Rank candidates by how much you already know. Someone you've worked with beats someone a trusted person vouches for, and both beat a stranger from an event. Full Scale's guide to technical co-founders ranks strangers last and says they should only get close after a real trial.
Public shipping evidence (a launched product, an open-source repo, a former employer's engineering blog) is useful, but only as a prompt for questions. You can't tell from a GitHub profile whether they made the decisions or inherited them. Ask what they chose, what they'd change, and what went wrong.
Good looks like specific, unflattering detail. Walk away from vague claims of having "built everything" that fall apart when you ask who else was on the team.
2. Run a paid, time-boxed trial before any equity
Define a project with a real deliverable and a date, and run it for about four to six weeks. NYU's entrepreneurship FAQ on finding a technical co-founder recommends a short, defined project of that length to test fit. It doesn't say the project should be paid. Full Scale does recommend a paid trial or contract phase before committing equity. We agree with Full Scale, and the reasoning is our judgment: pay creates a clean commercial relationship, lets either side leave without hard feelings, and stops the trial from quietly becoming a free build that you then feel obliged to reward with a founder stake.
During the trial, watch three things:
- Whether they bring you bad news early, or let a slipped date surface on the day.
- Whether they make reversible decisions alone and flag the irreversible ones.
- Whether they tell you when you're wrong about the business, not only about the technology.
Good looks like a shipped deliverable, a few honest disagreements, and no surprises. A missed deadline with no warning is a red flag, a point Altar's guide to finding a technical co-founder also makes.
3. Get an outside technical review of their decisions
You can't judge the answers, so hire someone who can. Pay a technical advisor or fractional CTO for a day to review the candidate's decisions: the stack choice, the architecture sketch, the estimates. Ask the reviewer to score the reasoning, not the polish.
Give them a question list to put to the candidate:
- Why this stack, and what would make you switch?
- What breaks first at ten times today's load?
- What would you deliberately not build yet?
- How long will this take, and what is that estimate based on?
Altar suggests benchmarking a candidate's estimates against outside advisors and treating a gap above 50% as a reason for caution. That's Altar's heuristic, not a measured threshold, so use it as a prompt for a conversation rather than a pass/fail line. The wider point holds: Chris Loy's guide to interviewing a technical co-founder argues that non-technical founders should seek a knowledgeable second opinion, because their own interviewing only reaches as far as their own domain.
For the take-home and live-defence mechanics, how to judge a senior developer you can't code-review covers them, and we won't repeat it here.
Good looks like a reviewer who says the candidate explains trade-offs clearly and can defend them. Walk away if the candidate refuses to be reviewed at all.
4. Test how they disagree
This is a test we designed, not an established method. Pick a real open decision, such as a product priority or a build-versus-buy call where you hold a view. Ask each of you to argue the other side as well as you can. Then see who moves on evidence.
You're looking for a person who changes position when given a good reason, and holds it when given pressure alone. Deference is a warning sign (you'll get a yes-person who resents you later). So is stonewalling, where every disagreement turns into a contest of who has more authority on the topic.
While you're on it, put decision rights on the table. Who has the final call on product, on hiring, on fundraising? Two people who each assume the answer is "me" will discover it at the worst moment.
Good looks like a disagreement that ends with a decision and no residue. Walk away if the discussion can't end without one of you conceding to keep the peace.
5. Call their past co-founders and cap-table partners
Employee references tell you about output. Co-founder references tell you about partnership. Ask for the names of people they've built with before, or investors and early colleagues who watched them, and call them. This is our recommendation rather than a sourced practice.
Ask what happened when things went badly. Who left, and why? What would they do differently? How did the candidate behave under money pressure? Then compare the story to the one the candidate told you in step 1.
Good looks like consistent accounts, including some criticism. Walk away if no past partner will speak, or if the stories don't match.
6. Put the earn-in in a written co-founder agreement
Undocumented equity is a common source of co-founder disputes. Write down what's earned, when, and what happens if someone leaves, and have a startup lawyer in your country draft it. The next section covers what it should contain.
Good looks like an agreement both of you sign without wanting to renegotiate it a month later. Walk away from anyone who wants the full stake upfront with no vesting.
What should the co-founder agreement and vesting say?
Treat this as a checklist for the conversation with your lawyer. These are negotiable conventions, not law.
Start with vesting. Seibel describes the typical Silicon Valley setup as four years of vesting with a one-year cliff, so that anyone who leaves or is fired within a year walks away with nothing. In Germany, Orrick's founder FAQ on vesting says a GmbH founder's shares can be subject to vesting, but it has to be agreed contractually, and it cites a four-year period with a twelve-month cliff as typical. Nothing happens automatically, so if it isn't in the paper, it doesn't exist.
The usual mechanism is reverse vesting: founders hold their shares from day one, and the company can reclaim the unvested portion if they leave (Orrick describes this for a German GmbH; the mechanics differ by country). Leaver definitions typically decide how much of the unvested stake the company can reclaim and on what terms, which your lawyer sets. Orrick describes bad leaver cases as typically fraud, gross misconduct and similar bad-faith actions, with good leaver covering any other circumstances, and some deals add a grey tier between them. Agree these definitions while you still like each other.
The rest of the checklist:
- IP assignment, so everything they build belongs to the company.
- Roles and decision rights, matching the answers from step 4.
- Full-time commitment, with any side projects declared.
- A deadlock process for when two founders disagree and can't resolve it.
- What happens when the trial converts to equity: the start date of the vesting clock and whether trial time counts toward the cliff.
Founder vesting is a founding stake, which makes it different from an employee grant tied to continued employment.
Which red flags should end the process?
Any one of these is enough to stop and reconsider.
| Red flag | Which step reveals it | What to do |
|---|---|---|
| Refuses a paid trial or a written agreement | 2 and 6 | End the process |
| Won't be reviewed by an outside technical person | 3 | End the process |
| Can't explain a trade-off in plain language | 3 | Ask the reviewer to probe further, then decide |
| Nobody who worked with them will talk to you, or the stories conflict | 5 | End the process |
| Wants full equity upfront with no vesting | 6 | End the process |
| Divided attention across side projects | 2 and 6 | Write the commitment into the agreement, or end it |
| Concedes every disagreement, or never concedes | 4 | Discuss it openly once, then decide |
The side-project one is easy to wave away. Altar flags divided attention as a warning sign, and in a company with two founders, half a founder is a serious gap.
What this means for your next step
Your decision is binary: commit equity to this person, or take the paid alternative. The six steps exist so that you make it with evidence instead of chemistry.
If the trial or the review fails, you haven't lost the project. You've lost a few weeks and a trial fee, which is cheap next to an unvested stake you can't easily reverse. Our judgment is that the fallback is a first senior engineer at an agreed rate, and the co-founder search can keep running in parallel, because a paid hire doesn't close that door. If the candidate passes, move straight to the agreement before anything else gets built on a handshake.
Either way, budget for the outside review and the lawyer now. Both cost far less than the cap-table problem they prevent. For the paid route, how founding engineers are hired in Europe is the sensible next read.
Hiring founding engineers through HighCircl
If the trial fails and you decide a paid engineer comes first, HighCircl's vetting has four stages run by senior engineers, and about 1 in 10 applicants passes. A shortlist arrives within 72 hours. If the engagement isn't working, HighCircl replaces the engineer at no additional recruitment cost, and a permanent-hire buyout is 18% of annual gross, disclosed from the start. See how a founding engineer search starts.
FAQ
How long should a co-founder trial last?
About four to six weeks is the range NYU's entrepreneurship team suggests for a short, defined project. In our view, anything shorter won't show you how they handle a slipped deadline or a disagreement, and anything longer means running a startup on a trial basis. Adjust for a candidate who keeps a day job, but keep the deliverable and the date fixed.
Should a technical co-founder be paid during the trial?
We think yes, as a matter of judgment. Full Scale recommends a paid trial before equity, and the reasoning is practical: it keeps the arrangement commercial and either side can walk away cleanly. If they're keeping a day job and working part-time, scale the payment to the hours rather than skipping it.
Is a four-year vest with a one-year cliff standard for co-founders?
It's the common starting point. Y Combinator describes it as a typical setup, and Orrick cites the same structure for Germany. It's convention, not law, so negotiate it with a startup lawyer in your own country, and write it into the agreement because in a GmbH vesting only exists if it's agreed contractually.
What if a co-founder wants equity before the trial ends?
Don't grant shares before the vesting terms and the agreement are signed. A candidate who pushes for shares before you've seen them work, or before there's paper to protect either of you, is showing you how they'll behave later. Finish the trial, do the review, then sign the agreement.
Can an AI tool vet their code for me?
A tool can summarise a repository and explain what a function does. In our view, it's poorly placed to tell you whether the architecture suits your business, whether the estimates are honest, or whether you can work with this person. Use it to prepare better questions for your outside reviewer, not to replace them.