Strategy days, or someone who does the work. What your Tuesday actually needs.
“Fractional CTO” has become a crowded title. Search for it and you will find hundreds of consultants offering strategy days, architecture reviews and roadmap sessions. Useful work. But when an owner tells me they are considering one, my first question is always the same: who is going to do the engineering? In most of those conversations the honest need is not a chief technology officer for a few days a month. It is a pair of hands that stays.
What a fractional CTO actually does
A fractional CTO is an advisory role. They help you make technology decisions: build versus buy, how to structure a team, whether your architecture will hold as the business gets bigger, what to ask vendors. They work in sessions and documents. The good ones earn their fee when you face a genuinely strategic question, an acquisition, a rebuild decision, a hiring plan for a product team.
What they do not do is patch your server on a Tuesday night, rebuild the automation that silently stopped running, or notice that your database has been slowing down for three weeks. Advice does not keep systems up.
What a fractional engineer does
Fractional engineering is the delivery layer. The systems themselves, built or adopted, then monitored, maintained and improved, month after month, by the same person. That means the infrastructure the business sits on, the site that represents it, the data that runs it and the automations that save your team hours, all held as one connected system with one person answerable for the joins between them.
Strategic questions still get answered, because an engineer who runs your systems has opinions grounded in your actual setup rather than a slide deck. But the advice is not what the retainer is for. It is for things working, and for somebody answering when they do not.
The test: what does your Tuesday need?
Strip the titles away and ask what the business needs on an ordinary Tuesday. If the answer is decisions, board-level guidance and a technology strategy your investors will read, you want the CTO. If the answer is that the site should be fast, the backups should be real, the integrations should not fail silently, and somebody competent should own all of it, you want the engineer.
A rough sizing rule, and it is a rule of thumb rather than a finding: businesses under about fifty people almost always need the engineer first. The strategy questions they face are real but occasional, and they get answered inside the retainer rather than as a separate line item.
Can you have both?
Yes, and above a certain size it is a sensible pairing: a fractional CTO setting direction, an engineering function delivering it. But sequence matters, because strategy applied to systems nobody maintains is decoration. If you can only afford one, buy the one that keeps the lights on, then buy the thinking once there is something stable to think about.
Neither of them starts with a rebuild
Worth saying, because this question often arrives attached to a fear. Bringing in an engineer does not mean replacing what you already have. Where a system exists and works well enough, it gets adopted as it stands, and from a fixed date one person is answerable for it. Building from scratch is the other route, not the default one.
The cost side of this decision is in the in-house comparison, and what a retainer covers month to month is on the Operate page. If you are not sure which role your situation calls for, that is a fair question to bring to the free conversation that opens the audit. It runs about twenty-five minutes and establishes whether this is a problem I can solve. If the honest answer is that you need a CTO rather than me, you will hear it there. The audit itself is €450, fixed before it starts and credited in full against a build or a retainer if one follows, and the contact page sets out what it covers.