How to Find a Technical Co-Founder When You Cannot Code
The short answer
Find a technical co-founder by making yourself worth joining first, then sourcing directly. Build proof of demand, define the engineering decisions the co-founder will own, shortlist 40-60 engineers whose public work shows they have solved your class of problem, contact them yourself, and evaluate through a paid 60-90 day build rather than an interview.
Key takeaways
- Strong engineers do not decline because the idea is bad. They decline because the offer transfers all the risk to them and keeps all the control with you.
- Proof of demand beats a pitch deck. Signed letters of intent, a waiting list or paying pilot customers change the conversation more than any equity number.
- Search for engineers who have solved your specific class of problem, not for the word CTO. Titles are the least informative field on a profile.
- You can assess technical judgement without being technical: use a paid build, a written technical decision memo, and two independent reference calls.
- An outsourced build is a legitimate bridge, not a substitute. It buys evidence that makes the co-founder search easier.
The most common brief I get from first-time founders is some version of: I have the idea, the market and the customers, I just need a technical co-founder. It is usually said as if the technical part were the easy half of the problem to fill. In practice it is the half where the market is smallest, the buyer is most sophisticated, and the offer on the table is weakest.
This article is written for the non-technical founder who is serious. It covers why good engineers say no, what you can do about it, where the people you want actually are, and how to judge technical ability when you cannot read code yourself.
Why strong engineers decline co-founder offers
It is worth understanding the economics from the other side of the table. A senior engineer in a competitive market has a well-paid, low-risk alternative available at any time, usually within a few weeks of deciding to look. That is the baseline your offer competes with.
Against that baseline, most co-founder approaches ask the engineer to give up salary, absorb the technical risk, absorb the build timeline, and accept a minority equity position in a company whose commercial evidence consists of the founder saying customers will definitely want this. The four objections I hear most often, in order of frequency:
| Objection | What it means | What answers it |
|---|---|---|
| There is no evidence of demand | You are asking me to take market risk as well as technical risk | Letters of intent, a paid pilot, a waiting list with real names, a pre-order |
| The split is not serious | 5-10% for building the entire product signals I am a contractor with a lottery ticket | A defensible split, written down, with the reasoning and a vesting schedule |
| I would be the only technical person deciding everything | There is no one to argue with and no one to hire against | A named budget or plan for the first two engineering hires |
| The founder cannot tell good engineering from bad | My judgement will be second-guessed on the wrong axis | Evidence you can hold a technical trade-off conversation without pretending to be technical |
None of these objections is about your enthusiasm. They are all about the distribution of risk. The work of attracting a technical co-founder is largely the work of moving risk off their side of the table.
Make yourself worth joining before you start searching
A search you launch before you are fundable to an engineer will burn the best names in your market, and those are exactly the names you cannot re-approach in six months. Spend four to eight weeks making the offer real first.
Build proof of demand you can put in a message
- Signed letters of intent. Even non-binding ones, on the customer letterhead, with a named person and a number attached.
- A paid pilot. One customer paying anything at all outranks fifty enthusiastic conversations.
- A waiting list with real organisations on it, not an email count.
- Recorded discovery calls or written findings from twenty customer conversations, with the objections included rather than edited out.
- A working prototype, however unglamorous. A clickable design, a spreadsheet model, a no-code build that a customer has actually used.
The prototype point deserves emphasis. Non-technical founders often assume they must wait for an engineer before anything exists. That has not been true for several years. A no-code or AI-assisted build that five customers have used badly is worth more in a co-founder conversation than a specification document, because it converts your claim about demand into an observation.
Decide the split before the first conversation
Not the exact number, but the range and the reasoning. Ranges I see hold up in practice, on the assumption that the technical co-founder joins pre-revenue and takes little or no salary:
| When they join | Cash | Typical equity range |
|---|---|---|
| Pre-product, pre-revenue, full time, no salary | None | 30-50% |
| Prototype exists, some demand evidence, no salary | None | 20-35% |
| Paying pilots, small pre-seed raised, reduced salary | 30-60% of market | 8-20% |
| Post-seed, market salary, senior hire framing | Market | 1-5% as an option grant |
If the number in your head is below the relevant range, you are not offering a co-founder role. That is a perfectly reasonable position, but say so, and search for a founding engineer instead. Mislabelling the role is the single fastest way to lose credibility with strong candidates, because they can read the split and work it out immediately.
Search for the problem, not for the title
The word CTO is close to useless as a search term. It appears on the profiles of people running three-hundred-person engineering organisations and on the profiles of solo consultants, and it is largely absent from the profiles of the people most likely to say yes: staff engineers, tech leads and principal engineers who have never held the title but have done the work.
Search instead for the class of problem you need solved. A workable pattern is to describe the hardest technical constraint in your product and find people whose history shows they have hit it before.
| Your product | Hardest constraint | What to search for |
|---|---|---|
| Compliance tooling for banks | Passing a bank security and procurement review | Engineers at fintechs that sell to tier-one banks; anyone who has written publicly about SOC 2, DORA or ISO 27001 implementation |
| Clinical decision support | Regulatory approval and clinical data handling | Engineers at companies with a CE mark or FDA clearance; contributors to health data standards |
| Real-time logistics | Low-latency routing at scale | Engineers who have run production systems in mapping, ride-hailing or delivery |
| AI product on top of foundation models | Evaluation and cost control, not model training | People who have shipped and publicly discussed an LLM product in production, including its failure modes |
The right-hand column is the one you can actually search. It combines hard filters, such as company, seniority and geography, with a description of experience that lives in a career history rather than in a skills tag. Once you have that description, generating a shortlist of forty to sixty names is a research exercise of a few days rather than a networking campaign of several months. The general method is in How to find a co-founder.
Where these people are visible
- Open-source repositories in your problem space: maintainers, frequent contributors, and the people who write the thoughtful issue comments rather than only the code.
- Conference programmes. Anyone who has given a talk about operating a system like yours has publicly demonstrated both the experience and a willingness to explain it.
- Engineering blogs of companies with your constraints. The named author of the post about migrating a bank integration is a better lead than any recruiter database entry.
- Technical writing and newsletters, where people describe trade-offs they made and got wrong.
- Second-degree connections of engineers you already respect. Ask two or three specific people for names, not for introductions.
How to assess technical ability when you are not technical
You do not need to evaluate code. You need to evaluate judgement, and judgement is legible to a non-technical observer if you set up the right situations.
- 1
Ask for a technical decision memo
One page: how they would build the first version, what they would deliberately not build, what they would regret in a year, and what they would need from you. You are reading for whether they name trade-offs and constraints, or only technologies. A memo that lists a stack but no constraints is a bad sign.
- 2
Run the disagreement test
Propose a technical approach you have heard somewhere and hold it lightly. A strong candidate will disagree, explain why in terms you can follow, and change position if you produce a good counter-argument. Anyone who cannot explain a technical point to you without condescension will not be able to explain it to a customer or an investor either.
- 3
Commission a paid build
60-90 days, paid at a fair rate, with a defined outcome you can observe: a working slice of the product that a real user touches. Watch three things: whether the estimate held, whether the scope was renegotiated openly, and whether problems arrived as early warnings or as surprises.
- 4
Get one technical friend to review the work
Not to judge the person, but to answer three narrow questions: is this maintainable by a second engineer, are the obvious security basics present, and is anything here an unusual choice that would need explaining. An hour of a senior engineer's time, paid, is the cheapest insurance in the entire process.
- 5
Take two references who worked under or beside them
Skip the managers. Ask peers and reports what happened when the person was wrong, and what they are like in week ten of a hard project. Ask each reference for one more name and call that person too.
The alternatives, and when they are the right answer
Sometimes the honest conclusion is that you should not have a technical co-founder yet. The alternatives are not failures; they are different risk profiles.
| Option | Best when | The real cost |
|---|---|---|
| Agency or contract build | You need evidence of demand and the product is well understood | Cash, plus a codebase your eventual co-founder may want to replace |
| Founding engineer on salary plus options | You have raised or have revenue, and want control retained | Cash and a smaller pool, since the upside is smaller |
| Fractional CTO | You need architecture and hiring judgement, not hands on keyboard | Limited hours and no long-term ownership of consequences |
| Build it yourself with no-code and AI tooling | The first version is genuinely thin and the constraint is demand, not engineering | A ceiling you will hit, usually at the first real customer with a security review |
Any of these can be a bridge. The reason to treat them as a bridge rather than a destination is that each one buys you evidence, and evidence is exactly the currency that makes the co-founder search work. A founder approaching engineers with three paying pilots and a working prototype is running a completely different search from the one they were running six months earlier with a deck.
A note on what not to do
- Do not ask for an NDA before the first conversation. It signals inexperience and, in a technical community, it is discussed.
- Do not describe the role as needing someone to just build the MVP. It tells the reader you view engineering as execution rather than as a source of decisions.
- Do not offer equity in exchange for a fixed deliverable. That is a contract with worse terms for both sides, and it will not survive first contact with a changed requirement.
- Do not run a search in which every candidate is a friend of a friend. It feels safer and it systematically excludes the strongest people in your market.
- Do not skip written agreements because it is early. A one-page memorandum covering split, vesting, roles and what happens if someone leaves takes an hour and prevents the most expensive category of dispute.
Frequently asked questions
How much equity does a technical co-founder get?
A technical co-founder joining pre-product and pre-revenue with no salary is typically in the 30-50% range. Once a prototype and some demand evidence exist, 20-35% is more common. After a pre-seed round with a partial salary, 8-20% is typical, and post-seed the role is usually a founding engineer with a 1-5% option grant rather than a co-founder. All of it should vest over four years with a one-year cliff.
Can I find a technical co-founder with no money and no product?
Yes, but the offer has to compensate elsewhere. Without cash you need evidence of demand, a serious equity split and a clear division of decisions. Founders who have letters of intent, a paid pilot or a used prototype convert far better than founders offering only an idea, because they have moved market risk off the engineer's side of the table.
Should I hire a CTO or find a technical co-founder?
Hire if you can pay a salary and want to retain control and equity; look for a co-founder if you need someone to absorb risk and own technical decisions outright. The deciding question is whether you want the technical direction to be argued with you as a peer or executed within a scope you set.
Where do I find technical co-founders?
The highest-signal sources are open-source repositories in your problem space, conference speaker lists, engineering blogs of companies with your constraints, technical newsletters, and the second-degree connections of engineers you respect. Co-founder matching platforms and hackathons work as secondary channels but give you little control over who enters the pool.
How do I know if a technical co-founder is any good?
Use three instruments you can read without being technical: a one-page technical decision memo that names trade-offs rather than technologies, a paid 60-90 day build with an observable outcome, and two reference calls with peers or reports rather than managers. Have one senior engineer you trust spend a paid hour reviewing the trial work.
Is it a bad sign if a technical co-founder wants a salary?
No. It is information about their circumstances, not their commitment. Many excellent engineers have dependants or visa constraints that make zero salary impossible. What matters is that the cash and the equity are traded off against each other consistently and written down.