Fractional CTO, Full-Time CTO, or a Senior Engineer?

Search for a fractional CTO and you mostly get rate cards. Page after page of agency landing pages that decided the interesting question is what one costs, then arranged everything else around getting you onto a call.

The interesting question is whether you need one at all, and a fair share of the time the honest answer is no.

Disclosure before anything else, because the rest is worth less without it: I do fractional CTO work. Read this the way you would read a builder telling you which walls are load-bearing. I have an interest in the outcome, and the only part of this post that earns your attention is the part where I argue against my own service.

A fractional CTO is a senior technical leader who owns architecture, hiring and technical strategy for a company part-time and on an ongoing basis, without being an employee of it.

A fractional CTO is a senior technical leader who owns architecture, hiring and technical strategy part-time, on an ongoing basis, as a contractor rather than an employee. The load-bearing word is ongoing. Fractional describes how much of the week, not how many weeks.

Four roles routinely get thrown into the same bucket, and each one implies a different contract, a different set of decision rights and a different exit.

Hire against the wrong row and the failure is quiet. Nobody can point at the clause that caused it. You just notice, around week three, that the person you brought in is present for a third of the problems they are being blamed for.

Match the role to your bottleneck rather than to your ambition. Here is the decision tree I would walk you through in a conference hallway, compressed into rows.

Read the last column first. Hiring mistakes at this level are almost never chosen. They are defaulted into.

A fractional CTO is the wrong call in four named situations: you have no product and no funding, your team already knows what to build, you want someone accountable for a delivery date, or what you actually want is someone to write the code.

No product, no funding, non-technical founder. You need a cofounder. Not because a contractor cannot build the thing, but because the first version will be wrong and you will need someone whose upside depends on being there for version four. Cash buys attention. Equity buys stubbornness.

Your team already knows what to build. If the engineers can articulate the next two quarters and disagree only about sequencing, adding a part-time authority figure above them mostly adds a meeting.

You want someone accountable for a date. A fractional CTO cannot own a delivery date they are absent for four days out of five. Anyone who accepts that accountability at two days a week is selling you comfort.

What you actually want is someone to write the code. Part-time leadership that also ships features is an arrangement everybody agrees to and nobody gets. The leadership work loses every time, because the code has a ticket number and the hiring plan does not.

There is a blunter version of this argument. CB Insights' March 2026 analysis of 431 VC-backed startups that shut down since 2023 puts running out of capital at 70% and poor product-market fit at 43%, and the list of leading causes contains no engineering-quality category at all. Companies rarely die of bad architecture. They die of building a good thing nobody wanted, or of running out of runway while doing it. If you cannot yet say who your product is for, a technical leader is not your constraint — what actually moved Codelit's numbers was distribution, and I say that as someone whose entire product is architecture.

You need a full-time CTO when the job stops being about systems and starts being about people. In practice that is when engineering is past eight or so, you are hiring continuously, and the questions arriving each morning are about humans.

Going from four engineers to thirty-five taught me that the transition is not a headcount milestone. It is a change in what the questions are about. Below the line, most of what lands on a technical leader is a system question: is this the right database, will this hold at ten times the load, do we split this service. Those questions batch. You can hold them for a Tuesday.

People questions do not batch. A resignation, an offer being negotiated, two senior engineers who have stopped talking to each other, a performance conversation that needed to happen last month. They arrive on their own schedule and they decay if they wait. A part-time leader either becomes a bottleneck or quietly hands the people work to someone who never agreed to do it.

There is a second trigger with nothing to do with headcount. When technical decisions start carrying company-level risk on a weekly cadence — regulated data, an enterprise security review, a platform migration that could take the business offline — the technical leader has to be in the room where company decisions get made. That room does not meet on your two days.

The answer is a senior engineer when you already know what to build for the next two quarters and the only thing standing between you and it is hands on keyboards. That is a throughput problem, and throughput problems do not improve when you add a strategist above them.

Founders reach for a CTO title here because "we need better engineering" sounds like a leadership gap. Usually it is a capacity gap wearing a leadership costume.

The test I would apply is small enough to do in your head. Can you write down, unaided, the next five things the product has to do and roughly why? If yes, hire someone to build them. If you can list the five things but cannot defend the reasoning in front of a technical investor, that gap is judgement, and judgement is what fractional work is for.

That distinction is a real skill and not a knowledge one. Watching engineers learn system design convinced me that most people can define every component correctly and still not know which constraint calls for which. A very good senior engineer will have that judgement. A very good senior engineer will also, in most cases, not want to spend their week in hiring loops and board decks. That is not a criticism of anyone. It is why the roles are separate.

A working engagement has three things written down before the first invoice: a fixed number of days per month, an explicit list of which decisions the fractional CTO owns outright versus advises on, and a defined deliverable at thirty days. Miss any one of the three and the engagement drifts regardless of who you hired.

Days, not hours. Hours invite timesheet arguments and encourage both sides to pretend that thinking is billable in fifteen-minute units. Days force a real conversation about presence.

Decision rights, written down. The single most useful sentence in the agreement names what the fractional CTO can decide without you: hiring bar and levelling, architecture, vendor selection under some threshold. Everything else is advice, and advice you can ignore is fine as long as both people know that is what it was.

The thirty-day deliverable. A written technical assessment, in four parts:

• The architecture as it actually is, not as the README claims.
• The top risks ranked by what they would cost in money or time, not by a severity label.
• The next two hires, with levels and what each is accountable for.
• One thing to stop doing.

Reading a codebase and drawing what is genuinely in it takes up most of the first two weeks, which is a large part of why I built the feature that reads a GitHub repo and draws its architecture. The other half of the job is pattern recognition, and reverse-engineering 55 real-world architectures for Codelit's template library is a fair proxy for what that buys you: not a better opinion, a faster one.

Pick the structure that matches what you are buying — availability, a deliverable, or a decision — and go in knowing what each one quietly incentivises. I am not publishing a rate card here. The number moves with scope far more than any page claiming to know it will admit, and the shape of the deal changes the outcome more than the size of it does.

Whichever structure you pick, the thing to protect is the ability to end it cleanly. A one-month notice period on both sides does more for the quality of the advice than any clause about deliverables, because it removes the incentive to be agreeable.

I decline two kinds of engagement. The first is where the founder wants a title on a slide. The second is where the decision has already been made and what is wanted is ratification.

Renting a CV. A named technical leader as fundraising decoration, with no intention of anyone doing the work. It falls apart the moment an investor asks what the person actually decided, and there is nothing to point at. It is also, less politely, a form of misrepresentation I do not want attached to my name.

The pre-decided decision. Someone has already chosen the rewrite, the platform, or the offshore team, and wants a senior technical voice to say it out loud so the internal disagreement stops. Agreeing makes me a rubber stamp. Disagreeing ends the engagement in week two with a founder who feels ambushed. Either way the company paid for theatre.

There is a version of that second one which is fine, and it is worth naming: bring in an outside technical voice before the decision, and say explicitly that "you are wrong" is an acceptable answer. That engagement is useful and I will take it every time.

Google's 2025 DORA report, published in September 2025 from a survey of nearly 5,000 technology professionals, put it in a line I keep coming back to — "AI doesn't fix a team; it amplifies what's already there." Outside help works the same way. A fractional CTO is amplification. If the underlying thing is a founder who wants agreement rather than information, amplification makes it worse.

Run this decision backwards and it gets much faster. Work out which roles your situation disqualifies — no funding disqualifies most cash hires, a growing team hiring weekly disqualifies part-time leadership, a fully specified roadmap disqualifies a strategist — and see what is left standing. It is usually one option, and it is usually not the one the search results are trying to sell you.

If what is left is a senior engineer or a technical cofounder, go and hire one. You do not need to email me first.

If what is left is a fractional CTO, start a conversation, and open it by telling me what you think is broken rather than what you want to buy. The first version of that sentence is almost always more useful than the second.