Plato - Cofounder Job Description Generator
Write the role description for a cofounder or founding engineer, and get the interview plan to go with it: what to probe, what to ignore, and how to tell the difference.
Named after Plato, whose Symposium tells of people searching for their other half. Finding a cofounder is much the same search.

A co-founder, CTO or founding engineer job description makes you decide what you actually need before you start meeting people, and it has two halves: the role as a candidate reads it, and the assessment plan as you need it. The first half attracts the right people. The second half is the one founders skip, and it is the reason so many co-founder searches end in a nice conversation with someone who cannot do the job. Describe your startup in the tool below and it writes both, with an interview scorecard, a work sample and the red flags worth watching for.
When a free tool is not enough
The expensive mistake is hiring the wrong cofounder, not hiring slowly.
A cofounder is the least reversible decision you will make, and most founders assess for one by having a nice conversation. We screen technical people for a living, and we will assess a candidate you found yourself on an ad-hoc basis, which is a few hundred pounds against a grant you cannot take back.
How to use Plato, the Cofounder Job Description Generator
Pick the role you are actually offering
Technical cofounder, commercial cofounder, founding engineer or first product hire. They are different offers with different risk and different equity, and conflating them is the most common way a search goes wrong.
Describe the product and the evidence
What it does, who uses it, and how far along you are. Traction changes what you can offer and who will take it, more than the sector does.
Say who is on the team and where the gap is
Be honest about the hole you are filling. A description written around a gap you have not admitted to produces a role nobody can succeed in.
Read the assessment half first
Sending the description is the easy part. The scorecard, the work sample and the red flags are what decide whether the person you hire was the right one.
Get a second technical opinion before you sign
If you cannot judge the technical skill yourself, borrow someone who can. A network favour, or an ad-hoc assessment. Either beats guessing on a grant you cannot reverse.
Founding engineer vs CTO vs technical co-founder
These three get used interchangeably, and underneath them are two completely different offers. Getting it wrong is how an offer collapses in week six, after both sides have spent a month assuming different things.
A cofounder takes founder risk and founder equity. They are in it whether or not you raise, probably unpaid or barely paid for a while, and their shares vest over years. You are choosing someone you will still be working with in five years, on the worst day of the company.
A founding engineer, usually your first engineering hire, is an employee. Salaried, meaningful options rather than founder equity, joining something that already exists and taking a real but smaller risk. The best ones are often better engineers than the cofounder you were looking for, because they are not also being asked to take a mortgage-sized bet.
CTO is a title, and it can go with either offer. A technical co-founder usually takes it from day one, on founder terms. A founding engineer might grow into it, or end up reporting to a CTO hired later as a senior employee.
Be specific in the description about which one this is, including the numbers. "Cofounder-level" with employee equity is a phrase that gets found out in the offer conversation and costs you the candidate.
Writing something a good candidate will read
The people you want are not looking at job boards. They are employed, doing well, and being approached regularly. The description has to be worth their attention in the first paragraph, and the first paragraph is not your mission statement.
What gets read: what the product does, who uses it, what evidence exists that anybody wants it, and what this person would own in their first six months. What does not: "fast-paced environment", "rockstar", a list of twelve technologies, and anything about passion.
Cut the must-haves to four or five. Every extra requirement filters out good people who could have done the job, and the ones who apply anyway are the ones who read requirements loosely, which is not a selection criterion you wanted.
- Lead with the product and the evidence. Traction, however small, beats ambition.
- Name the first six months as deliverables, not responsibilities. "Ship the clinic onboarding flow" rather than "own the product roadmap".
- State the salary or the lack of one, and the runway. People find out in conversation two; being upfront buys trust and saves everyone a week.
- Give an equity range with a reason, and say it is negotiable. A single number reads as take it or leave it.
- Be honest about what is hard. The candidate you want is choosing a problem, and a problem with no difficulty in it is not interesting.
Interviewing a CTO or technical co-founder, properly
Most founders assess a technical cofounder by talking to them, liking them, and checking they can name the right technologies. That tests likeability and vocabulary. Neither predicts whether this person can build your first version or lead the team that replaces it.
The thing to probe is what they have actually done, in detail, with numbers. Not "tell me about a project you are proud of" but "walk me through the hardest decision on that system, what you rejected, and what it cost you six months later". Strong people have specific, slightly boring answers with trade-offs in them. Weak ones have polished narratives with no losses in them.
For a technical cofounder, two separate questions matter and they are rarely found in the same person. Can they build the first version themselves, quickly, alone. And can they later hire and lead engineers better than themselves. Somebody who can only do the first becomes the bottleneck at fifteen people. Somebody who can only do the second cannot help you for the first year.
Then there is the part no interview reaches: what happens when the two of you disagree. Work together first. A paid week on something real tells you more than six conversations, and it is the cheapest due diligence available on a decision this permanent.
- Ask for specifics with numbers, and follow up twice. The second follow-up is where rehearsed answers run out.
- Set a short paid work sample drawn from your real product. A few hours, not a weekend, and pay for their time.
- Ask what they got wrong recently and what it cost. An answer with no real failure in it is a failure of the answer.
- Reference their last two roles, and speak to someone who reported to them, not only to their manager.
- Work together on something real before anyone signs anything.
When to bring someone else in
If you are not technical and you are hiring a technical cofounder, you are being asked to judge a skill you do not have, on the least reversible decision in the company. That gap is structural, so it needs a structural fix.
The usual fix is to borrow judgement. Someone senior and technical who owes you nothing, sitting in on a technical conversation and telling you afterwards what they heard. Many founders can find that in their network for the price of lunch, and should.
We do it commercially too, either as recruitment where we run the search, or as an ad-hoc technical assessment of somebody you found yourself. The second is the cheaper one and is usually what founders actually need: the pipeline is fine, the shortlist is the problem. Either way, get a second technical opinion from somewhere before you sign a grant you cannot take back.
What this tool cannot do
It writes from your description. It has never met your team, seen your product or spoken to a candidate, so the output is a strong starting draft rather than a finished document. Edit it, particularly the must-haves, where your context beats any generic judgement.
It cannot assess anybody. The scorecard gives you the questions and what good and thin answers sound like; the judgement in the room is still yours, and for a technical role that you cannot judge yourself, that is a real limitation to plan around.
It will not settle your equity number. The output gives a range with reasoning, because the number is a negotiation between two people and anything more specific from a tool would be invented.
Before your first result we ask for your name, work email and company. What you type on that run travels with your details to our CRM, inbox and team chat, so a person can read it and reply. After that, what you type goes to the model. We keep each result, which can quote what you put in: it is emailed to you as a PDF and saved in our CRM. Either way, keep personal data and anything confidential out: describe the company rather than naming individuals, and you get the same output from "one commercial founder, one part-time contractor".
Frequently asked questions
A cofounder takes founder risk and founder equity, usually with little or no salary, and is in it whether or not you raise. A founding engineer is employee one or two: salaried, with meaningful options rather than founder shares, joining something that already exists. Be explicit about which you are offering, because conflating them is how offers collapse at the final conversation.
Decide first what you are offering. A technical co-founder usually holds the CTO title on founder terms: founder risk, founder equity, little or no salary. A CTO hired later is a senior employee on a salary and options. If what you need now is senior technical judgement, a fractional CTO can cover it part-time until you can hire. Then write a startup CTO job spec that names the product and the evidence anyone wants it, the stack, the first six months as deliverables, the salary and an equity range with a reason. Assess both halves of the job, building the first version and later leading a team, and work together on something real before anyone signs. If you cannot judge the technical skill yourself, bring in someone who can.
It depends on when they join, what exists already, whether they are full-time, and whether they are paid. Someone joining at incorporation to build everything is in a different conversation from someone joining a company with revenue and a working product. The tool gives a reasoned range rather than a number, because the number is a negotiation and any tool that hands you a single figure is guessing.
Probe for specifics and follow up twice, which surfaces rehearsed answers without needing to evaluate the technology. Set a short paid work sample on something real. And borrow technical judgement from someone who owes you nothing, whether that is a favour from your network or a paid assessment. Do not rely on liking them; on this decision, likeability is the variable most likely to mislead you.
Ones that make a candidate talk about something they actually did, in detail, with numbers. Ask them to walk you through the hardest decision on a system they built, what they rejected and what it cost six months later, and what they got wrong recently. For a startup CTO or technical co-founder, test two things separately: can they build the first version themselves, and can they later hire and lead engineers better than themselves. Follow up twice, because the second follow-up is where rehearsed answers run out. The tool on this page writes an interview scorecard for your role, one row per area, with the question to ask and what a strong and a thin answer sound like.
A short, paid, realistic one, drawn from your actual product and timeboxed to a few hours. Multi-day unpaid take-homes filter for people with free time rather than people who are good, and the strongest candidates simply decline them.
For the candidate: what the product does and the evidence that anyone wants it, what they will own in the first six months written as deliverables, the tech stack, four or five genuine must-haves, the salary or the lack of one, the runway, and an equity range with a reason. For you: a scorecard with the questions to ask and what strong and thin answers sound like, a short work sample and the red flags to watch for. The tool on this page writes both halves. If you do not give it a stack, it recommends one and labels it as a recommendation.
Four or five. Each one should be something you would genuinely reject an otherwise strong candidate over. Longer lists do not raise the bar; they filter out good people who read requirements literally, and select for people who do not.
Free, with three runs per person and no paid tier. Before the first result we ask for your name, work email and company, and for you to accept the terms. What you type on that first run travels with your details to our CRM, inbox and team chat, so a person can read it and reply. After that, what you type goes to the model. We keep each result, which can quote what you put in: it is emailed to you as a PDF and saved in our CRM. Keep personal data and anything confidential out: describe the company rather than naming people, and you will get the same output.
Related from Metamindz
- Technical recruitmentWe run technical searches as engineers, and we will assess a candidate you found yourself on an ad-hoc basis.
- Fractional CTOIf the reason you need a technical cofounder is that nobody senior is making the technical decisions, there is a version of that you can rent.
- Equity and cap table plannerModel what a cofounder grant does to your ownership before you put a number in an offer.
- All free tools
Also known as: CTO Job Description Generator, Founding Engineer Job Description, Job Advert Generator.
Published