The CTO you can’t hire — and why that’s not your problem yet
Most non-technical founders try to hire a CTO at the wrong moment. The right move, until Series A, is almost always a delivery partner. Here’s how to tell where you are.
A founder we worked with last year told us, over coffee in São Paulo, that he had spent four months looking for a CTO. He’d talked to twenty-three people. None of them said yes. Two of them said yes and then ghosted him before signing. He finished the coffee and asked a question that, at that point in his fundraise, was an emergency: “Who do non-technical founders hire when they can’t get the CTO?”
That’s the wrong question. The right one is: should you be hiring one at all?
Most early-stage founders we meet are convinced the answer is yes. They’ve read the playbook. The playbook says: hire the technical co-founder, give up 20–30% of the company, ship the product, raise the round. The playbook is forty years old in startup-time. It was written when there was no other way to build software. There is now.
Until Series A — and sometimes well past it — the right move for a non-technical founder is almost never to hire a CTO. The right move is to work with a delivery partner who behaves like one. The difference is subtle, the cost is dramatic, and most founders don’t see it until they’ve already given the equity away.
What a CTO actually does (and why you don’t need most of it)
Before we argue about whether to hire, let’s be specific about what we’re hiring. A real CTO at a venture-backed company does five jobs. They architect the product. They hire and manage the engineering team. They own the technical roadmap and trade-offs against the business roadmap. They represent engineering to the board, to investors, and to enterprise customers. And — usually fifth on the list, despite what founders assume — they sometimes write code.
For a pre-seed or seed-stage company, jobs three through five are almost entirely fictional. There is no engineering team to hire and manage. The board doesn’t care yet. Enterprise customers don’t exist. What you actually need, in the first eighteen months, is the first job — somebody who can architect the system — and a small team that can execute on that architecture without the founder becoming the bottleneck.
A delivery partner does the architect part and provides the team. A CTO hire does the architect part and you provide the team. In one model, the resourcing problem is solved on day one. In the other, it becomes the CTO’s first project — and it usually takes six months and consumes most of the runway you raised the round on.
The math founders don’t run
Here’s the comparison nobody walks through with founders, because the people in the room usually have a stake in one side of it.
Hiring a CTO at seed: you give up roughly 15–25% of the equity and pay a salary somewhere between R$ 30k–60k/month in Brazil or US$ 200–280k/year in the US. They join, then they spend their first two months recruiting. They make their first two hires. Three months in, you have three engineers, no product yet, and the highest fixed cost on your P&L is the engineering team. You will spend the next twelve months managing the manager who manages the team. The CEO who told you they “don’t want to be a tech manager” will, in fact, be a tech manager.
Working with a delivery partner: you pay a project fee — for a typical first version, somewhere between R$ 200k–600k or US$ 80k–200k spread over four to nine months. The team is staffed on day one. The architecture conversation happens with a senior person before the first line of code. You get to launch, ship to your first paying customer, and iterate — without burning runway on people you can’t yet productively manage.
After eighteen months, when the company is bigger and the cost of partner-led development per feature starts to outpace the cost of in-house, that’s when you hire. By then you know exactly what kind of CTO you need, because the codebase tells you. You hire someone who fits the architecture you already have, instead of guessing what architecture you need before any code exists.
“But I want a co-founder”
This is the part of the conversation where founders push back. They don’t want to outsource the product. They want a partner. They want somebody who lies awake at night thinking about the same problem they do. They want a name on the deck.
We hear that. It’s a real preference, and it’s not wrong. But it’s worth being honest about what it costs and what you actually get.
A technical co-founder who joins at seed is rarely the person who builds the company you’ll have at Series A. The skills the company needs at month two — write code, ship fast, set up the database — are not the skills it needs at month twenty — hire engineers, set engineering culture, partition the system, deal with security audits. The number of CTOs who can do both well, in succession, on a sub-50-person team, is small. The number who think they can is large.
If you want a co-founder, hire one for the part of the business where you actually have a gap that lasts. A go-to-market co-founder if you’re a domain expert. A product co-founder if you’re commercial. A second commercial co-founder if you’re a builder. The technical work — until you have enough of it to keep a team busy full-time, on something you understand well enough to direct — can be partner-led without losing anything important. The exception is when the technical work is the product’s defensible moat (a research-heavy AI product, a deep infrastructure play, a hardware-software combo), and even then most founders overestimate how much of their early code is the moat.
How to tell which side you’re on
Two questions. Answer them honestly, in writing, before you take a meeting with the next CTO candidate.
First: Could I, right now, write a one-page brief for what we want built in the next six months — what it does, who uses it, what success looks like, what it must integrate with? If yes, you don’t need a CTO; you need a delivery partner who can take that brief and run. If no, the gap is upstream of engineering — it’s product clarity. A CTO won’t fix that for you faster than another month of customer conversations would.
Second: If a senior engineer joined tomorrow, what would I assign them in their first month? If the honest answer is “figure out what to build” — that’s a product gap, not an engineering gap. If the answer is “build feature X and Y, here are the specs” — you don’t need a hire, you need execution. If the answer is “manage the four engineers we just raised the money to hire” — you’ve talked yourself into the wrong problem.
The only honest answer that justifies a CTO hire at seed is: we have a complex technical decision that compounds over years, the product’s defensibility lives in that decision, and I cannot in good faith outsource it. That’s a real situation. It’s also a rare one. Most founders aren’t in it; they think they are because the playbook told them they should be.
What “delivery partner” actually means
We use the phrase carefully, because it’s been so abused by agencies that it almost means nothing. A delivery partner — the kind we mean — sits closer to a fractional CTO than to a body shop. The relationship has four properties.
The senior engineer who scopes your project is the same person who reviews the code six months in. There is no handoff from sales to delivery, because the people who promised the architecture are the people who built it. You see how decisions get made — every architecture call is a real conversation, not a deliverable. The trade-offs are visible. The team writes code you can hire someone else to maintain when you eventually do hire in-house, because the hand-off is a stated goal of the engagement, not an afterthought.
That last property is the one most founders miss when they evaluate partners. The wrong partner builds a system only they can maintain, because that locks the founder in. The right partner builds something a future CTO can pick up cleanly — that’s how you know the partner has skin in your long game, not just this quarter’s invoice.
When to actually hire
There are signs. The clearest one is workload — when there is enough engineering work, every week, that paying for it through a partner becomes more expensive than running an in-house team, and that workload has been steady for at least six months. That usually happens between Series A and Series B for B2B SaaS, and earlier for capital-light consumer products.
The second sign is technical decision velocity — when the rate of decisions you have to make is high enough that the partner relationship’s communication overhead becomes a tax. At that point an in-house lead is faster, even if not strictly better.
The third sign is talent gravity — when the engineers you want to recruit will only come if you have a CTO who’s a credible technical leader they want to work for. This sign comes later than founders think; senior engineers are happy to join a fast-growing company with a strong delivery partner if the founder is honest about the model and there’s a real path to the first VP/CTO hire.
When you do hire, hire someone who fits the codebase the partner built, not the abstract idea of “a CTO.” The partner’s job is to make that hire easier, not harder. That’s the test.
The quiet thing nobody says
We’ve watched dozens of seed-stage founders go through this decision. The ones who hired too early almost all said, twelve months later, that they wished they hadn’t. The ones who chose a partner first almost never said the opposite. The asymmetry isn’t subtle.
There’s a reason. The pressure to hire a CTO at seed is mostly social. It comes from investors who like a complete-looking team on a deck. It comes from peers who took the same decision before custom-software partnerships were credible. It comes from the founder’s own anxiety about being the only person on the cap table who doesn’t write code. None of those are arguments about what’s good for the company. They’re arguments about what’s comfortable for the founder.
The uncomfortable answer is that, for the first eighteen months, most non-technical founders don’t need a CTO. They need a senior person who has built this kind of thing before, a small team that can execute, and the discipline to keep their own role pointed at customers, distribution, and the business — not at the engineering org chart they don’t have yet.
When that day comes, hire. Until it does, build.