Do you write code in this role?

No, and a fractional arrangement that drifts into writing features has stopped working. One or two days a week disappears into a sprint very easily, and then the decisions the role exists to make are the ones that never get made. Reading code, reviewing pull requests and pairing on an architecture problem are in scope. Owning tickets is not.

How many days a week, and can that change?

Usually one or two, agreed monthly in advance. It can change with notice, and it is normal for it to start higher for the first month while everything is being read and everyone is being met, then settle.

What happens if production breaks at two in the morning?

Whatever the agreement says, written down before it happens rather than assumed. Out-of-hours expectations, who is called first, and what is and is not covered are all defined at the start, because the worst time to discover that nobody agreed this is during an outage.

How is this different from having an advisor?

An advisor gives you an opinion. This role makes decisions and carries them — choosing the architecture, running the hiring loop, telling the board what the technical risk actually is, and being the person whose name is on it when a call turns out to be wrong.

Can you hire and manage our engineers?

Yes, and it is a large part of what the role is usually bought for — job descriptions written for engineers rather than for HR, a screening script, a practical exercise under two hours, a scorecard, and reference questions people answer honestly. Whether hiring and delivery accountability are included changes the monthly fee.

How does the engagement end?

Deliberately, which is the whole intention. Either the company grows into a full-time hire and we run that search and hand over, or the work reduces to a monthly review. Either way the decision record goes with it, so the next person inherits reasons rather than mysteries.

Consulting, Product & Talent

Fractional CTO

Part-time technical leadership — one or two days a week spent on architecture, hiring, delivery and board risk, with a name attached to each decision.

From: $1,500–$10,000/mo
Typical time: ongoing
Usually bought by: Funded startups

What this actually solves

The round closed, the chief executive is not technical, and there are three developers who are individually good and collectively pointing in slightly different directions. Deployments break sometimes and nobody can explain why. Then at the first board meeting an investor asks what the technical risk is, and there is no answer in the room — not a bad answer, no answer. That question is the one that usually generates the enquiry, because it exposes something the founders had already half-noticed and had no vocabulary for.

A full-time chief technology officer is out of reach at this stage, and the honest reason this seat gets filled part-time is not cost. It is that the thing being bought is accountability for decisions, and accountability does not scale with hours. Somebody has to choose the architecture and live with it, decide who is hired and who is let go, tell the board what is actually fragile, and be prepared to have their name on a call that turns out to be wrong. That is not advice, and it is not something a document can carry.

What we do, and in what order

The first month — read everything, meet everyone, write the risk list. Code, infra, the deploy process, the backlog, and a conversation with every engineer individually. It ends in a written technical risk register you can hand to a board, ranked by what it would cost you rather than by technical severity. Weeks one to four.
A weekly delivery review. One hour, every week, on three questions — what shipped, what is stuck, and what is a risk. Held on the same day so it survives busy weeks. One hour a week, ongoing.
One architecture decision a month, written down as a record. The date, the reason, the alternatives considered, and why they were rejected. A page each. This is the cheapest insurance in the whole engagement, and the only reason a decision made this year is still understood in two. A page a month.
Hiring, end to end. A job description written for engineers that states honestly what is broken here, because good candidates find out anyway and hiding it costs you the offer stage. A thirty-minute screening script with what strong and weak answers sound like. A practical exercise capped at two hours of unpaid candidate time, drawn from your actual problem domain, reviewable in twenty minutes, and never a puzzle. A scorecard of four to six criteria scored one to four, with at least two criteria a non-technical interviewer can use. Two to four weeks per hire, alongside everything else.
Board preparation. One page before every board meeting stating the technical risk in language a non-technical director can act on, so the chief executive is never in that room without an answer again. Half a day per meeting.
The unglamorous standing items. Vendor relationships, security basics, and backups that have actually been restored from rather than merely configured. Ongoing.

Tooling is genuinely secondary here — Linear or Jira to see delivery honestly, GitHub for code and pull requests, somewhere durable for the decision records, and a one-page monthly report in a fixed format so the trend is visible across months rather than restated each time.

What moves the price

The band is $1,500–$10,000/mo and the engagement is ongoing rather than fixed-term. Three things decide where in that band a retainer sits.

Days per week. The most direct factor. One day a week of judgement is a different commitment from two days that include standing in front of the team.

How much of it is decision-making versus responsibility. A fractional lead who advises sits at the lower end of the range. One who owns hiring decisions, delivery commitments and what gets said to the board is carrying materially more, and is priced accordingly.

Whether board and investor work is included. Preparing a technical section for a board pack, and being in the room to defend it, is a distinct commitment with its own preparation time and its own exposure.

What usually goes wrong

The role gets used as a senior developer. There is always something urgent, the person in the seat is capable of fixing it, and within two months the one or two days a week are being consumed by tickets. Everyone is busy and satisfied, and none of the decisions the role was hired to make have been made. The defence is a fixed weekly rhythm that does not move — the delivery review and the monthly architecture decision happen whether or not something is on fire.

Decisions live only in someone's memory. Two years later a new engineer asks why the system is built this way, the person who decided has left, and nobody can answer. With no recorded reason the team reverses the decision, and the company pays a second time for a problem it already solved. A written record per major decision costs an hour and prevents exactly this.

Nobody in the company is able to say no. Every other person in a young company has a reason to say yes — the salesperson has a deal, the founder has a promise, the engineer wants the interesting work. The absence of a single credible no is what produces a roadmap that cannot be delivered and a team that stops believing in dates. Being the person who says it, in a way that survives the meeting and gets written down, is a large part of what this seat is for.

See where the site stands before you brief anyone.

If the site is already live, start from what it scores rather than from a guess. The audit reports what it checked, what it found, and — the part most tools leave out — what it could not check, and why.

See the website audit Talk about this work

Questions people ask before they commit.

Do you write code in this role?: No, and a fractional arrangement that drifts into writing features has stopped working. One or two days a week disappears into a sprint very easily, and then the decisions the role exists to make are the ones that never get made. Reading code, reviewing pull requests and pairing on an architecture problem are in scope. Owning tickets is not.
How many days a week, and can that change?: Usually one or two, agreed monthly in advance. It can change with notice, and it is normal for it to start higher for the first month while everything is being read and everyone is being met, then settle.
What happens if production breaks at two in the morning?: Whatever the agreement says, written down before it happens rather than assumed. Out-of-hours expectations, who is called first, and what is and is not covered are all defined at the start, because the worst time to discover that nobody agreed this is during an outage.
How is this different from having an advisor?: An advisor gives you an opinion. This role makes decisions and carries them — choosing the architecture, running the hiring loop, telling the board what the technical risk actually is, and being the person whose name is on it when a call turns out to be wrong.
Can you hire and manage our engineers?: Yes, and it is a large part of what the role is usually bought for — job descriptions written for engineers rather than for HR, a screening script, a practical exercise under two hours, a scorecard, and reference questions people answer honestly. Whether hiring and delivery accountability are included changes the monthly fee.
How does the engagement end?: Deliberately, which is the whole intention. Either the company grows into a full-time hire and we run that search and hand over, or the work reduces to a monthly review. Either way the decision record goes with it, so the next person inherits reasons rather than mysteries.

Often taken together.

Start with the brief, not the invoice.

Send what you are trying to achieve. You get a written scope, a price and a date — or an honest “this is not the right service for that”.

Talk about Fractional CTO All Consulting, Product & Talent services