How to find and vet a CTO as a non-technical founder
Start with what you actually need: a co-founder who shares the risk, a fractional CTO who bridges the gap, or a full-time hire who runs your engineering. Each has different costs, different commitments, and different places to look. Once you have candidates, vet them with specific questions about real problems. The five diagnostic questions in this guide come from actual projects where the wrong technical decision cost founders months and money.
Co-founder, fractional CTO, or full-time hire?
The answer depends on your stage and your funding.
Technical co-founder. If you’re pre-funding and building a tech product, this is the strongest position. Sam Altman writes: “Have at least one technical founder on the team (i.e. someone who can build whatever the company is going to build)” (blog.samaltman.com). Michael Seibel, co-founder of Twitch and former CEO of Y Combinator, is blunter: “The tech co-founder is the stove. You’re not going to make the stew without the stove” (TechCrunch Disrupt SF, 2018). A co-founder shares ownership and risk. You give equity, but you gain someone whose incentives are fully aligned with the company.
Fractional CTO. When you have funding but aren’t ready for a full-time technical leader, a fractional CTO works as a bridge: someone who makes architecture decisions, vets your first hires, and keeps the technical side under your control while you search for a long-term partner. You pay for time, the code and accounts stay yours, and you’re not giving away equity for a role you might fill differently later.
Full-time CTO. This makes sense when you have product-market fit, a growing engineering team, and enough work for a dedicated technical leader every day. At this stage, you’re hiring someone to scale what already works.
The vetting questions below work for all three.
Where to look
Your own network is the strongest channel. People you’ve worked with, or friends who’ve built products, are easier to evaluate than strangers. Beyond that:
- YC Co-Founder Matching: free, profile-gated, the largest co-founder matching platform
- Wellfound (formerly AngelList): startup-focused roles for CTO and co-founder positions
- CoFoundersLab, Indie Hackers, r/cofounder: communities where builders look for partners
- Paid trial projects: post a real problem and see who solves it well. A few days of real work tell you more than any profile or interview
For a detailed checklist on evaluating any technical hire or contractor, see how to choose a developer or a team.
Five questions that reveal how a CTO thinks
These come from real situations where the wrong technical decision cost founders months. You don’t need to understand the technology to use them. Listen to how the answer is structured.
”What would our infrastructure look like if it were sized for the users we actually have?”
In one project, a SaaS with about two thousand users was spending more on cloud every month than on anything except salaries. A previous contractor had designed it for the scale the founder hoped to reach: a dozen separate services, each with its own database. Deploys took 40 minutes. The fix was merging into one application. The cloud bill fell by about 70%, deploys went from 40 minutes to under five.
Good answer: asks how many users you have, what traffic looks like today, and proposes the simplest setup that handles your real numbers with room to grow.
Worry if the candidate says “we need to build for scale from day one” without asking about your current numbers. Over-engineering at an early stage burns cash on infrastructure instead of on learning what customers want.
”Which parts of our product cause most of the problems, and does fixing them require starting over?”
A services marketplace had a codebase several years old. A new lead developer proposed rewriting it in a modern stack: six months with no new features. The incident history showed two areas behind almost all the problems: the booking calendar and the payout logic. Those two parts were replaced one at a time in about ten weeks, with features still shipping in between. The full rewrite was never needed.
Good answer: asks for the incident log and support ticket patterns before forming a view. Proposes replacing the worst parts first and keeping the rest running.
Worry if the candidate immediately agrees with a full rewrite or proposes their preferred technology before asking what’s actually broken. Joel Spolsky called rewriting working code from scratch “the single worst strategic mistake” for a software company (joelonsoftware.com, 2000).
”We want to build this in-house. Is that the part our customers actually pay for?”
A founder with a fresh round was about to hire three machine learning engineers to build custom speech recognition for a niche industry. Recruiting alone was planned for a quarter. But the product’s value wasn’t in recognizing speech better than existing providers. It was in what happened after: turning messy calls into structured records the customer could use. A hosted speech service with a custom vocabulary of industry terms covered the recognition well enough. One strong product engineer replaced the planned research team, and the first version reached customers in six weeks.
Good answer: challenges the build-vs-buy assumption. Proposes an evaluation on your real data before committing to a team.
Worry if the candidate starts planning headcount for the build without questioning whether building it yourself is the right move at this stage.
”If our developers disappeared tomorrow, which accounts could we still log into?”
One founder had worked with an agency for a year. Things were going well. A review found that the code repository, the cloud account, the domain, and the app store accounts were all registered to the agency. The founder was paying for the product but didn’t control any of it. Transferring everything to the founder’s company took two weeks while the relationship was still friendly. When the founder later changed teams, the handover took days instead of months.
Good answer: raises account ownership in the first conversation and insists all repositories, cloud, domains, and store accounts belong to your company from day one.
Worry if this topic doesn’t come up at all. A CTO who doesn’t think about operational control will leave you dependent on whoever happens to be writing the code.
”If an investor’s engineer looked at our product tomorrow, what would they flag?”
An AI startup had three weeks before investors’ technical due diligence. The founder asked for an independent look first, so there would be no surprises. The review found API keys sitting in the code history, only one engineer who knew how to deploy, and no documented answer to a question investors increasingly ask AI companies: what happens to customer data sent to the model provider. The team rotated every key, wrote and tested a deploy anyone could run, and documented the data flow. The review came back with no red flags.
Good answer: names specific gaps without being defensive. Has a plan to close them.
Worry if the response is “our code is clean, nothing to worry about.” Every early-stage product carries debt. A CTO who can’t see it will let it compound until it becomes someone else’s problem.
Red flags you can spot without technical knowledge
- They propose a technology stack before asking a single question about your product
- They can’t describe a technical decision they got wrong
- No questions about your users or your business model
- Their entire experience is at companies with hundreds of engineers, and they haven’t built anything from zero
- “I make all technical decisions” — at a startup, technical decisions are business decisions. A CTO who doesn’t see that will wall you off from your own product
What I’d do in your place
- Decide what you need first: a co-founder who shares the risk, a fractional CTO who bridges the gap, or a full-time hire. If you’re unsure, start with a paid trial project to test the working relationship before committing equity or a salary.
- Write down your product’s three biggest problems before any interview. The five questions above work better when grounded in your actual situation.
- Describe a real problem to every candidate and compare how they approach it. A paid working session on your actual codebase reveals more than any interview. The approach is described in how to choose a developer.
- Check references with founders, not engineers. The question that matters: “What specifically changed because of this person?”
- Make sure code, cloud accounts, domains, and app store accounts are in your company’s name from day one. A CTO who doesn’t insist on it isn’t thinking about your long-term position. If you’re just starting and need help defining scope, a startup launch guide walks through what to decide before any technical conversation.
If you want, we can review your situation and agree on a clear next step you can act on.