A technical co-founder who has run the company, not just the codebase.

The work overlaps almost entirely. The difference is the deal: a fractional CTO is capability you rent for a fee, a technical co-founder is capability you buy a share of the company with. Most businesses that ask me need someone to own the technology now, not permanently, and a fee is a great deal cheaper than equity for that. I’ve written the long version, with what equity costs and how vesting protects you, in Technical co-founder or fractional CTO.

Part-time CTO, virtual CTO, outsourced CTO and CTO as a service are other names for what I call fractional: senior ownership of your technology for a day or two a week, on a monthly fee. If one of those is what you searched for, you’re in the right place.

An interim CTO is a different job. It’s a full-time seat for a fixed period, to cover a departure or carry a company through a sale, and I don’t take those. I run a business of my own, so a day or two a week is what I can give and still do the work properly. How to tell which one you need is in Fractional CTO or interim CTO.

Every engagement I’ve taken started as a fixed fee. The equity was the client’s idea, afterwards. I’ve had investors on a cap table and taken them off it again, so I know what that costs on both sides.

Partnership happens, and it isn’t the thing being sold. It isn’t on the price list because it has no price: equity only when you raise it, and only after a fee.

Both, and the ratio depends on the engagement. The systems described in the case studies are mine: I designed them and I built them. What I’m not is a management layer that stopped being technical some years ago and now reviews other people’s decisions from a distance.

Then the work is direction, not throughput: architecture, standards, what gets built in what order, and the decisions that are expensive to reverse. That’s the arrangement I run in my own business: I’m CEO there and I manage the technical team.

A diagnostic is two weeks of concentrated attention. A retainer is a day a week or two, plus being reachable for a decision in between, with a considered reply aimed for within one working day. A support retainer is two days a month, for a system that is live and needs looking after. What I don’t do is spread myself across enough clients that none of them gets a real decision. The business needs ten right clients, not a hundred.

I aim to start a diagnostic within two weeks, and a retainer on a similar footing. Both depend on what is already running. You’ll get the real date on the first call rather than the one you want to hear, which is the same test I’d tell you to apply to anyone else in this category.

£2,000 a month for a support retainer of two days a month, £4,000 a month for a day a week, and £7,500 a month for two. The support retainer comes out at £1,000 a day. There are 4.33 working weeks in a month, so the weekly ones come out at £924 and £866 a day. The rate falls as the commitment rises, which is the shape you should expect. Ask anyone quoting you a retainer to show you the same sum, and be careful if they will not.

If you need less than two days a month, a few days a year, I work at my day rate of £1,000 as and when: booked in half days and invoiced for what is used. Nothing is reserved, so there’s no reply promise.

The weekly retainers cost less a day than my day rate of £1,000 because you’re committing, and the support retainer costs the same, because two days a month is too little to discount. Beyond the days, a retainer reserves a slot I can’t sell to anyone else, and it buys you reaching me between the scheduled days for a decision that cannot wait. On the support retainer the aim is a considered reply within two working days, because two days a month can’t hold the same slot a weekly retainer does.

The diagnostic is the one price that sum doesn’t apply to. It’s priced on what it settles, and two weeks is the window it’s settled in, not a count of billed days. All prices exclude VAT.

No minimum term. It runs month to month with 30 days’ notice either way. More than two days a week is possible and I don’t publish a price for it, because three days is most of one person’s week and I’d rather say that than pretend otherwise.

You hold something that runs without me: the system in production, the decisions written down as they were made, and a handover built continuously instead of assembled at the end. That’s what the deliver stage is for, and it’s the answer whether you leave after one piece of work or stay for years.

Plenty of this work doesn’t end at handover, because a system in production keeps generating decisions: what to build next, what is now the constraint, whether the thing you’re about to spend on is the right thing. A retainer exists for those. It runs month to month on 30 days’ notice, so it’s a judgement you make again every month. Being easy to leave is deliberate: it stops a retainer becoming a dependency.

Both, and the team part isn’t theoretical. I’ve built my own business to a core team of more than ten, and in earlier companies I was part of building teams of fifteen to twenty. That work was never only engineering: it covered operations and delivery as well, which is where most growing businesses break.

So the answer covers hiring, structure, standards and the unglamorous part where a team of three becomes a team of ten and stops running on conversation alone. I’m not a recruitment function, and somewhere past twenty you want a permanent leader in the building. My job by then is to make that hire land well and hand over the seat.

This is one person, not a rota, and if you need guaranteed cover you should hire a team. A bigger client doesn’t displace you: I take few engagements so that question doesn’t arise. Where a problem needs a specific skill I don’t have, or a gap needs covering, I can reach a small group of senior people I’ve delivered alongside for years. That’s a deliberate exception rather than a delivery model, and accountability doesn’t move with it. The contract stays with me and you deal with the same person throughout.

What I can control is how exposed you are when I’m not there. Everything runs on your infrastructure under your accounts, architecture decisions are written down as they’re made instead of kept in my head, and the handover is built continuously instead of at the end. The test I hold myself to is whether another competent engineer could pick the work up from the repository alone.

Holiday is planned into the availability we agree at the start, so it shows up in the schedule instead of arriving as news. Illness is the one nobody plans, and where it’s disruptive I make provision instead of leaving you to absorb it.

I carry professional indemnity insurance, and the certificate is available on request. If your procurement needs it named before anything starts, ask early and not late.

The commercial answer is the shorter one. Retainers run month to month, and either of us can end one with 30 days’ notice.

It can be, and it’s better raised now than discovered later. I’m co-founder and CEO of an education technology business, so if you operate in that market we should talk about it directly before anything else.

In practice that means a mutual NDA as a matter of course, being explicit about any sector overlap before an engagement starts, and my declining work where I couldn’t act wholly in your interest. If you want a sector restriction written into the engagement, ask for it. I’d rather lose a piece of work at the start than be the reason a founder worries about who else I talk to.

The case studies have the engineering in them: the trade-offs, the failure modes and the things that had to be designed around. Read one and judge it. There’s no logo wall on this site because a logo proves nothing.