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

Before asking what a fractional CTO costs, ask which decision keeps getting stuck. A missing architecture owner, an overloaded team and a founder who needs a technical partner are three different problems. One title will not fix all three.

I do fractional CTO work, so I have a stake in this question. My recommendation is to start by ruling it out. If the team needs a builder or a full-time owner, part-time advice is the wrong purchase.

The right hire depends on the work that lacks an owner and how often that work arrives. Write down the decisions and delivery responsibilities before choosing a role. The table below is a starting point for that conversation, not a rule based on company stage alone.

The last row matters. A question with an end date does not automatically need a retainer.

A fractional CTO is the wrong fit when the company needs more continuous ownership than the engagement can provide, when no one can implement the advice, or when the real request is endorsement of a decision already made. Scope cannot compensate for missing capacity.

If the team knows what to build and needs another experienced engineer, adding a separate strategy layer may slow it down. If no product exists and the plan is still changing every week, a long-term technical partner may be more valuable than a periodic reviewer.

Part-time leadership can include hands-on delivery, but the trade-off must be explicit. A feature deadline and a hiring process compete for the same days. Agree which takes priority and who owns the other when they collide.

I would also question whether the problem is technical at all. Building Codelit and finding a distribution path are related work, but a better architecture does not identify the right customer on its own.

The role needs more time when the queue of consequential decisions repeatedly exceeds the agreed availability. Look for delayed feedback, unowned incidents, stalled hiring and decisions made without the right context. Those are stronger signals than crossing an arbitrary team-size threshold.

Some architecture decisions can wait for a scheduled review. An incident, a resignation or a time-sensitive offer may not. A part-time engagement can work if an internal owner handles those situations and the escalation arrangement is realistic.

The failure I would watch for is informal overflow: the fractional leader quietly becomes full-time, or another engineer quietly becomes the manager. Neither arrangement is healthy if nobody agreed to it.

The first month should produce a shared technical picture and a small set of decisions the company can act on. The assessment should distinguish observed evidence from open questions. A roadmap without that foundation can simply formalise the assumptions that caused the uncertainty.

I would expect four outputs:

1. The architecture as it works today, including important dependencies and operating responsibilities.
2. A short risk list ranked by business impact, evidence and urgency.
3. Clear ownership for the next decisions, including any genuine hiring gap.
4. One concrete action to take, and one activity to stop or defer.

Code review is only part of the assessment. Speak to the people who deploy, support and use the system. A README may describe the intended architecture while an incident runbook reveals the one the team actually operates.

A repository architecture analysis can speed up orientation. It cannot independently establish traffic, recovery performance or whether the team trusts the deployment process.

Responsibility should be written in terms of decisions, deliverables and availability, not a broad promise to “own technology.” Both sides should know what the leader can decide, what remains advisory and who acts when the leader is unavailable.

The engagement structure should follow what is being bought. A recurring allocation supports continuity; a fixed-scope assessment supports a decision with an end date. Neither is inherently better.

A practical scope also protects the team. Engineers should not discover that an outside advisor can overrule their decisions only after a disagreement. Explain the arrangement and how technical disputes will be resolved.

Useful advice changes a decision and leaves the team better able to make the next one. It includes the trade-off, the evidence and the condition that would reverse the recommendation. A title on a deck or a list of fashionable tools provides none of that.

This is the same distinction I care about in system design teaching. Knowing the vocabulary is not enough. The value is choosing an approach that fits the constraint and explaining the cost clearly.

Two requests I would turn down are a leadership title with no real work behind it, and a review whose conclusion has already been agreed. An independent assessment has to allow “keep the current system” and “your preferred rewrite is unnecessary” as possible answers.

Before contacting a candidate, name the three decisions or outcomes you need help with and the coverage each requires. That short list usually exposes whether you need implementation, assessment, part-time leadership or a full-time partner. Start there rather than with a title.

If the answer is a senior engineer, hire one. If the answer is a scoped review, keep the scope bounded.

If the answer is ongoing technical leadership, tell me what keeps getting stuck. That is a much better opening than “we think we need a CTO.”