Find a technical cofounder by showing that you can help build the business, not just describe an application. Bring customer evidence, a clear account of your own responsibilities and a willingness to share decisions about the product.
The difficult part is rarely finding someone who can write code. It is finding someone who wants to own technical judgment, ongoing maintenance and company risk alongside you. If you want to specify every feature and keep all authority, you may be looking for a paid implementation relationship instead.
Bring evidence that changes a product decision
A polished pitch can be useful, but it should not be the only thing a prospective partner can inspect. Prepare an anonymised account of the customer's existing workflow, the failure you observed and what the customer does today to work around it.
Separate direct observations from your interpretation. “Three operators showed us the same manual handover” is different from “every operator needs our platform.” Explain what remains uncertain, including whether someone controls a budget or has permission to adopt new software.
Evidence does not have to mean revenue. It can mean documented interviews, a manual service, a permissioned test or a decision not to build after learning something important. Do not share recordings, customer names or private documents without the appropriate permission.
Explain what you will own after launch
A technical partner needs to know that your contribution continues when the first version exists. Write down the recurring work you will be accountable for: discovery, sales, onboarding, support, domain research or operational delivery.
Be specific about a normal week. Will you recruit interviews? Handle support tickets? Negotiate a pilot? Watch customers use the product? The statement “I will handle the business side” is too broad to evaluate and too easy to quietly change later.
YC's matching service is one discovery route. Whatever channel you choose, lead with a problem and a contribution rather than a request for someone to build your idea for equity.
Make room for technical disagreement
A cofounder is allowed to conclude that your proposed solution is too broad, unsafe or technically expensive. They may recommend a manual workflow, a simpler integration or a different initial customer. That is part of the role you are inviting them to take.
Ask questions that reveal judgment:
- What would you avoid building until we learn more?
- Which dependency could make this difficult to maintain?
- What should a human review rather than automate?
- How would we know if the prototype should be discarded?
You do not need to pretend to assess every implementation detail. If necessary, involve an experienced, independent technical reviewer with everyone's consent. Explain the review's scope and protect the person's work. A secret test or an unpaid production assignment is a poor beginning to a partnership.
Use a shared problem rather than a coding audition
Propose a short experiment in which each person has real work. You might recruit two potential users while the engineer tests whether a workflow can be demonstrated with synthetic data. Review the feedback together and document what changed.
Agree on time, expenses, access and use of the output before starting. If the task provides valuable commercial production work, discuss appropriate payment and legal arrangements. Calling something a cofounder trial does not make every unpaid assignment fair or appropriate.
YC treats discussion as a supplement to actual working experience.
A hypothetical example
Imagine a former clinic administrator who wants to simplify appointment follow-ups. She knows the workflow but has not proved that clinics want a new product. She approaches an engineer with a feature list and gets little interest.
She changes the invitation. She documents an existing process, obtains permission to discuss anonymised problems and offers to recruit feedback participants. The engineer suggests testing a narrow scheduling problem rather than building a broad medical assistant. They deliberately avoid real patient information during their exploratory work.
The administrator handles recruitment and learns that the biggest difficulty is staff handover, not messaging. The engineer can now evaluate a specific problem and the prospective partner's contribution. They may still decide against building together. Better evidence makes either decision more useful.
Check whether you need a cofounder at all
If you need a defined website, integration or prototype, a paid contractor may meet the need. If you need a continuing capability inside an established business, an employee may fit. Shared ownership becomes relevant when you want another person to help determine the company's direction and bear its uncertainty.
Budget constraints do not turn an employment need into a cofounder opportunity. Be honest if you cannot pay, and do not imply that an idea alone has settled the value of future work. A prospective partner is evaluating both the business and you.
Your next step is a one-page problem brief with three parts: customer evidence, your ongoing contribution and the uncertainty you want to explore together. That gives a technical founder something much more meaningful to respond to than “I have an app idea.”