When to hire your first CTO — and when not to

Knowing when to hire a CTO starts with the advice founders actually get, which is usually "hire a technical co-founder", and when that does not happen the fallback becomes "hire a CTO". Both skip the question of what the role is actually for at your stage, which is why so many early CTO hires end badly for everyone involved.

What the title attracts

Post a CTO role and you will get applications from people who want to lead an engineering organisation: set direction, build a team, own strategy. That is what the title means.

At five people, there is no organisation to lead. The work is writing the product, making the handful of architecture decisions that will matter for years, and being the person who says "that will take four months, not four weeks" to a founder who does not want to hear it.

Those are different jobs. Someone excellent at the second is often bored by the first, and vice versa.

The signals that you genuinely need one

Not headcount. Not funding stage. These:

You are approving decisions you cannot evaluate. Someone proposes a platform, a vendor, a rewrite. You have no basis on which to challenge it and no one independent to ask. That is the clearest signal, and the most dangerous position to remain in.

Technical choices have started to carry commercial weight. Compliance obligations, enterprise security reviews, data residency, uptime commitments in contracts. These need someone accountable who understands both sides.

Engineering has grown past what one person can hold. Somewhere around six to eight engineers, coordination becomes a real job rather than an overhead on someone's real job.

You are losing engineers and cannot tell why. Usually a leadership problem, and one you cannot diagnose from outside.

The cheaper options first

A senior lead engineer. Covers the technical judgement without the management overhead. The most under-used option.

A fractional CTO. One to two days a week from someone who has done it several times. Well suited to bounded needs: a first architecture decision, evaluating an agency, technical diligence, hiring your first engineers. Often better than a full-time hire for these, because the value is judgement rather than presence.

A technical advisor. A few hours a month, reviewing significant decisions. Cheap, and enough surprisingly often.

An agency with real accountability. If your build is bounded and you have someone reviewing the work, this defers the hire without leaving you exposed.

What a fractional CTO actually costs versus full-time

The cost comparison is usually more favourable to going fractional than founders expect, and worth stating in real numbers.

A full-time CTO in a competitive market commands a base salary typically in the £120,000–£180,000 range for an early-stage company, plus meaningful equity — often 2-5% for a true first hire — plus the overhead of a full-time senior person whose judgement you are paying for whether or not there is enough decision volume to use it fully. Over a first year, all-in cost including equity value is easily £200,000-plus.

A fractional CTO, engaged for one to two days a week, typically runs £2,000–£4,000 a week depending on seniority and market — call it £100,000–£200,000 annualised for two days a week, but critically, without the equity commitment and without a full-time headcount you may not yet have enough decisions to justify. For a company making perhaps one or two genuinely hard technical calls a month, two days a week of senior judgement covers the actual demand comfortably, and the cash cost is comparable or lower once equity is factored out.

The comparison shifts once there is a full engineering team to lead day to day — at that point the value of continuous presence starts to outweigh the flexibility of fractional engagement, and the full-time hire becomes the better trade. The signal is not a fixed headcount number so much as whether technical decisions are now dense enough, day to day, that judgement delivered twice a week has become a bottleneck.

Interview questions that actually predict fit

Beyond "do they say no to you," a few specific questions surface more than a generic technical interview does, because they test judgement under the actual constraints of an early company rather than abstract technical knowledge.

"Tell me about a time you deliberately chose the worse technical solution." Every experienced engineer has done this — shipped something they knew was not the right long-term answer because the business needed it now. The answer reveals whether they can hold two things at once: technical standards and commercial reality. Someone who cannot name an example either lacks the experience or is not being honest about it.

"What would you build differently if you knew the company might fail in six months versus definitely succeed in five years?" Tests whether they can calibrate technical decisions to actual business risk, rather than defaulting to either over-engineering for a future that may not arrive or under-building in a way that creates expensive debt if the company does succeed.

"Describe the worst technical decision you have seen a founder make, and how you would have handled disagreeing with it." This is really asking about the "say no to you" quality from a different angle — specifically, whether they have a constructive way of disagreeing rather than either capitulating or becoming obstructive. The mechanism they describe for pushing back matters more than the specific story.

"What is something in your area you are currently unsure about?" A candidate who claims certainty about everything is either inexperienced or performing confidence for the interview. Real technical leadership involves living with genuine uncertainty and communicating it honestly rather than projecting false confidence to reassure a founder.

If you do hire, hire for the next eighteen months

The most common mistake is hiring for the company you hope to be. A CTO who has run a hundred-person organisation will often be miserable and ineffective at eight people, where the job is writing code and making decisions personally.

Hire for the stage you are entering, and be explicit that the role will change. Good candidates find that clarifying rather than off-putting; the ones it deters were not right anyway.

What to test for

Whatever the title, test for three things:

Do they say no to you? In the interview. A candidate who agrees with your entire technical plan is either not paying attention or not going to protect you from yourself.

Can they explain a technical decision to a non-technical person? Not simplified into meaninglessness — genuinely explained, with the trade-off intact. This is most of the job.

Have they operated at your stage? Not your industry, not your stack. Your stage. The skills at eight engineers and eighty are close to unrelated.

What the startup CTO role actually covers day to day

Beyond the headline signals for when to hire, it is worth being concrete about what the role covers once it exists, because the mismatch between what founders imagine and what the job actually is causes most of the early hiring mistakes.

At an early company, the startup CTO role is roughly: writing a meaningful amount of code personally, particularly on the parts of the system that will be hardest to change later; making the small number of architecture decisions that lock in direction for years, and being accountable when they turn out wrong; owning the buy-versus-build calls for anything not core to the product; being the technical voice in any commercial conversation that touches engineering — a security questionnaire from an enterprise prospect, a compliance requirement from a regulator, an investor's technical diligence; and hiring the next few engineers well, since the people a first technical leader hires set the technical culture for everyone who joins after.

It is explicitly not, at this stage: managing a large team, since there usually is not one yet; running formal processes designed for organisations with more coordination overhead than a five-person team has; or being primarily a strategic or external-facing role, since the actual leverage at this stage comes from technical decisions made well and code shipped, not from presentations.

This is precisely why the title mismatch causes problems. Someone who has genuinely done the "startup CTO role" as described above — hands-on, decision-dense, still writing code — is a different candidate from someone whose CTO experience was at a two-hundred-person company managing several engineering directors. Both are legitimately CTOs; only one of them is suited to what an early company's version of the role actually requires.

The first technical hire beyond the CTO question

Not every early company's first technical hire is a CTO-track decision at all, and it is worth separating the two questions explicitly.

If the founding team is entirely non-technical, the first technical hire — whatever their title — is solving a different problem than the "when do we need a CTO" question this piece has focused on. That first hire needs to be someone who can single-handedly get a product built and keep it running, which is closer to the lead-engineer profile described earlier than to the CTO profile, regardless of what the offer letter calls them.

Where this gets confused is when a founder, uncertain how to describe the role, defaults to "CTO" as the title for whoever that first technical hire turns out to be — which is exactly the title-inflation problem this piece has argued against. The role can be senior, well-compensated, and genuinely load-bearing without being called CTO, and doing so preserves the option to bring in someone more senior later without the awkwardness of a title change.

The thing worth remembering

A non-technical founder who buys judgement deliberately — fractional, advisory, or through an accountable partner — consistently outperforms one who hires a CTO too early because it seemed like the responsible thing to do.

The failure mode is not the absence of a CTO. It is approving decisions you cannot evaluate, from people whose interests are not identical to yours.

How this connects to the alternatives

The decision covered here sits alongside a broader question about how to source technical judgement and capacity generally — our guide on hiring versus outsourcing engineering covers the same trade-off applied to the team as a whole rather than to a single leadership hire, and the two decisions are often made together: a company deciding not to hire a full-time CTO yet is frequently also deciding whether to build a team in-house or lean on an external partner for delivery capacity in the meantime.

If the path chosen is an external partner rather than a fractional CTO specifically, the questions worth asking of that partner are covered in how to choose a software development partner — many of the same signals apply, because in both cases you are trying to buy judgement from someone whose incentives you cannot fully verify from outside.

Reassess as the company changes

Whatever choice is made now — lead engineer, fractional CTO, full-time hire — is right for the company's current stage, not necessarily its stage in eighteen months. Building in an explicit reassessment point, tied to a milestone like headcount or funding rather than a calendar date, keeps the technical leadership structure matched to what the company actually needs rather than what felt right at a moment that has since passed.

In one sentence

Most early companies need a builder with judgement, not a manager with a title, and the two are easy to tell apart if you interview for the right thing.

A practical next step

Before writing a job description, answer this question honestly: are you currently approving technical decisions you do not understand well enough to challenge? If yes, that is the actual gap to fill, and it may be filled faster and more cheaply by a fractional CTO or a trusted advisor than by a lengthy full-time search — start there, and let the full-time hiring question wait until the company has genuinely outgrown that lighter-weight answer.

The signal worth trusting most

Of every signal covered in this piece, the one worth trusting most is also the simplest: notice the moment you catch yourself approving a technical decision because you trust the person proposing it, rather than because you actually understand why it is right. That moment, repeated with increasing frequency, is the clearest indication that the company has outgrown informal technical judgement and needs someone accountable for it specifically — whatever that role ends up being called.

One more thing worth saying

Whichever path is chosen, the goal is the same: someone accountable for technical judgement whose incentives you understand and whose reasoning you can follow, even if you cannot evaluate the technical detail yourself.

The founders who get this right

The founders who make this decision well are the ones who resist the instinct to hire for reassurance and instead hire, or buy fractionally, for the specific judgement gap they can actually name.