What is a fractional CTO? What they do and when you need one
A plain explanation of what a fractional CTO does, what you are actually paying for, what it costs, and how to tell whether your company needs one yet.
If you are building a company without a technical background, you have probably been told you need a fractional CTO. The explanations are mostly written by people who sell the service, and they tend to describe the role in terms of what it costs relative to a full-time hire, as though the only interesting thing about it is the discount.
Those explanations are accurate as far as they go, but they miss what the job actually is. Here is a breakdown of what the role covers, what you are really paying for, what it costs, and how to tell whether your company needs one yet.
What a fractional CTO is
A fractional CTO is an experienced technology leader with diversified experience, who works with your company part-time and on an ongoing basis, instead of joining as a full-time hire. Most arrangements run somewhere between a couple of days a month and two days a week.
The word fractional describes the time, not the seniority. You are working with someone who has done the job before, for a fraction of the week rather than all of it. This distinction matters, because the lower price is sometimes read as a lower standard of judgment, and it is not the same thing. You are buying less of someone’s time, not a cheaper version of their thinking.
The ongoing part is what separates this from the arrangements it gets confused with. Someone brought in full-time for a fixed few months to cover a gap is an interim CTO. Someone who gives you an hour a month of high-level input is an advisor. A fractional CTO sits between those: not there every day, but close enough to the work and around for long enough to be responsible for how the technology turns out.
The work is the problem, not the technology
Most descriptions of this role list technical responsibilities: architecture, stack selection, security, hiring. Those are real, and a fractional CTO does all of them, but they are the second half of the job, and treating them as the whole thing is why founders sometimes end up disappointed with the help they receive.
The first half is working out what the problem actually is.
When you ask for something to be built, what you describe is usually a solution you have already arrived at. You have thought about your business, noticed something that is not working, and translated it into a feature. By the time it reaches a developer, the original problem has been lost, if it was ever stated at all, and what gets built is the translation rather than the thing you needed.
Finding your way back to the real problem is not a technical skill. It is a matter of asking careful questions and listening to the answers, of talking to the people who will actually use the thing, and of being willing to say that the request as stated does not make sense yet. It is genuinely difficult, most technical people are not trained in it, and it is where the largest amounts of money get saved or wasted.
This is also why range matters more than depth in this role. Someone who has only ever worked on one kind of system tends to reach for the answers that worked there. Someone who has worked across several different kinds of problem is quicker to notice when a familiar answer is being applied to a problem that does not fit. This is usually called “pattern recognition”. The technology decisions follow from understanding the problem properly. When the problem is understood, most of the technical choices become straightforward and cheap. When it is not, no amount of technical skill will rescue the result.
What the job actually involves
Day to day, the work falls into four areas.
Deciding what gets built, and what does not. Scoping a first version around what you are trying to learn rather than around a feature list, and being clear about what is deliberately being left out.
Judging whether the work is any good. An independent read on whether your developers or agency are delivering well, whether a milestone is genuinely finished, and whether an estimate is reasonable. The point of independence is that the person assessing the work has no stake in the answer being yes. Most of the time quality turns out to be less a matter of the builders’ skill than of how complete the context they were given was. There is a lot you can judge for yourself here without being technical, which is covered in how to tell if your developers are actually any good.
Choosing suppliers and tools. Deciding between building something, buying it, and assembling what already exists. Reading contracts and quotes before you sign them, and making sure you own what you paid for, which is not automatic and catches people out regularly.
Building the team. Knowing when to make your first engineering hire, running a process that reveals judgment rather than trivia, and keeping the work accountable once someone is in the seat.
There is a fifth thing that rarely appears on the list, and for a non-technical founder it may matter most. A good fractional CTO leaves you more able to handle technology decisions yourself. Not by teaching you to code, which would take years you do not have, but by explaining the reasoning behind each decision until the pattern becomes familiar. If by the time the arrangement ends you understand your own product no better than when it started, something has gone wrong.
What a fractional CTO costs
Fractional work is almost always a monthly retainer, sized to the number of days you need, agreed before anything starts. It is rarely charged by the hour, because the value is in the decisions rather than the time recorded against them.
In the UK, published rates for two to three days a week generally run from around £6,000 to £16,000 a month. Arrangements of a few days a month rather than a few days a week cost proportionally less, and that lighter shape is what most pre-seed and seed companies actually need. What you are buying is not a quantity of days, it is the quality of the decisions made in them.
The comparison worth making is not against a developer’s day rate, because you are not buying the same thing. It is against the cost of a full-time technology leader. In the UK that means a salary well into six figures, plus employer national insurance, pension contributions, equity, and a recruitment fee that is often twenty percent or more of the first year. A fractional arrangement gives you the same standard of decision-making for a small fraction of that, because you are buying a small fraction of the week.
There is a second comparison that is harder to put a number against and is usually the larger one. Rebuilding a product that was assembled without a plan, paying to maintain a system nobody understands, or spending nine months on a first version that could have taken three, all cost considerably more than the retainer that would have prevented them. The difficulty is that this cost is invisible when you are deciding whether to spend the money, and obvious a year later.
Whatever the number, you should know it and the scope it covers before you start, and you should be able to change it as your needs change. Long lock-ins are a warning sign in this kind of work. The guide to fractional CTO costs goes further into the rates, the pricing models, and the questions that show what a price is actually buying.
Fractional, interim, advisor, or agency
Several arrangements sound similar and get used interchangeably, which makes it hard to work out what you are being offered. The differences change who is accountable, and for how long.
A fractional CTO works part-time and on an ongoing basis. Right when real technical decisions are being made, you have never had a CTO, and a full-time hire is not yet justified.
An interim CTO works full-time for a fixed period. Right when a technology leader has left and the role cannot sit empty while you recruit a permanent replacement. The work is defined by the gap it fills.
A technical advisor gives you a few hours a month. Right when you want someone to talk things through with and you are comfortable owning the decisions and the follow-through yourself.
A development agency builds what you specify, on a project basis. Right when you know what needs building and need the capacity to build it. Worth remembering that an agency is not independent of its own work, so it is not the right party to ask whether that work is any good.
A technical co-founder is full-time and permanent, usually for equity rather than salary. Right when you have found someone who believes in the idea enough to make the commitment.
The distinction that matters most is between advice and accountability. An advisor gives you an opinion and leaves the decision with you. A fractional CTO makes the call alongside you and is answerable for how it turns out. If you could reliably weigh technical input on your own, you would not need the help in the first place.
What your situation calls for
The honest answer to whether you need one depends on where you are, and in some situations the useful thing is something else.
If you are still working out whether anyone wants what you are building, you do not need to wait until you have that answer. Getting to a clear view of the problem before anyone writes code is part of this work, and it is the cheapest part of it. What would be a mistake is commissioning a full build on the strength of an idea nobody has tested yet.
If what you need is more hands to build, that is a developer or an agency rather than a fractional CTO. Hiring senior judgment when what you lack is capacity means paying a high rate for someone with very little to direct. Someone in this role can still help you choose the supplier, read the quotes before you sign, and judge the work once it starts.
If you need deep expertise in one narrow area, a specialist will serve you better. Security, a specific regulation, a particular scaling problem: these want depth rather than range. A good fractional CTO will tell you plainly where their expertise ends and help you work out what to ask the specialist for, and whether the answer you get back is good or actionable.
If you already have a technical leader your team trusts, this needs care rather than enthusiasm. Bringing in a second senior voice above someone who is doing the job well tends to undermine them, and that helps nobody. It works when that person wants it: someone to mentor them, or to help them navigate a particular project or a growing team for a while. That is a decision to make together with them rather than around them.
How to tell whether you need one
The test is not your funding stage or your headcount. It is whether the product and technology decisions being made right now have someone experienced genuinely accountable for them.
Ask yourself who is responsible for deciding what gets built next, and how you would know if that decision were wrong. If the answer is that it lands on whoever happens to be building, or on you, or that nobody has really been deciding at all, then you have the problem this role exists to solve.
The follow-up question is how much of that you have. If it is one decision, buy advice. If it is a steady stream of them and you have nobody senior to weigh them with, that is what a fractional arrangement is shaped for. If it is genuinely a full week of them every week, hire a full-time CTO, because at that point you need one.
If you want to work out which of those you are, book a free 30-minute call. If a fractional CTO is not what you need, I will tell you that on the call, and you will still leave with a clearer view of your next step. You can also read more about how an engagement works in practice, including how scope and cost are set.