The question arrives early and it is the right question. The answer you get is usually a number, which is the wrong answer, because the number depends on a choice nobody has made explicit yet.
There are three ways this role gets priced. They can put the same person in your organisation at similar totals and reward completely different behaviour.
Model one: the day rate
You buy days. Ten a month, four a month, whatever the arrangement says.
What it optimises for. Being needed. Not cynically, but structurally: a person paid per day of attention has no financial reason for your dependence on them to decrease. The good ones fight that instinct. The model does not help them.
Where it works. A defined piece of expert work with a visible end. An architecture review. A vendor evaluation. A migration plan. Something where the day count is roughly knowable in advance and the deliverable is a document you can hold.
What to watch. The meter runs on meetings, on reading your documentation, on the phone call after the meeting. That time is real work and it should be paid. But if nobody agrees in advance what is billable, you will discover the answer on the invoice.
The clause that fixes it. A monthly cap, in days, with anything beyond it requiring your written approval before it happens rather than after. Not because you expect abuse, but because a cap forces the conversation about priorities that a day rate otherwise avoids.
Model two: the monthly retainer
You buy availability. A fixed amount per month, a stated number of days included, and the person is reachable in between.
What it optimises for. Continuity, which is genuinely what you want from technology leadership. Somebody who knows your systems, was in the room for the last three decisions, and does not need re-briefing each time.
It is also the honest model for a role that is partly on call. Nobody schedules the incident.
Where it breaks. In the quiet months. Two consecutive months where nothing needed deciding, and the retainer starts to look like a subscription to nothing. This is the most common reason these arrangements end badly, and it is avoidable.
The clause that fixes it. A quarterly review with a written scope for the next quarter, and a genuine exit at each review, without penalty. A retainer that can be stopped every quarter gets renegotiated on merit. A retainer with a twelve-month lock-in gets renewed on inertia, and the service degrades quietly long before anyone notices on the invoice.
Model three: fixed fee on scope
You buy an outcome. This tool, working, by this date, for this price.
What it optimises for. Finishing. The vendor carries the overrun, so the vendor wants a tight scope, clear acceptance criteria and no surprises. Those are the same things you want, which is unusual enough to be worth noticing.
Where it does not apply. Leadership itself. Scoping, arbitrating between vendors, deciding what not to build: none of that has a fixed shape, and pricing it as though it did means either the vendor is not really doing it, or they have priced a large cushion you are paying for.
The honest hybrid, which is what we do: fixed fee on the deliverables, and a bounded commitment with a stated end on the leadership. Both halves have a defined finish. Nothing runs open-ended because nobody remembered to stop it.
What the three models cost, and why the comparison is usually run wrong
Comparing headline rates compares the wrong thing. Two arrangements at the same rate produce very different totals, for three reasons that never appear in the proposal.
Ramp-up, paid twice. Every new arrangement includes weeks where the person is learning your systems rather than improving them. That cost is real and it recurs each time you change provider. A cheaper rate that you re-pay every eight months is not cheaper.
Your own team’s time. Ten days of vendor time can consume fifteen days of internal time in meetings, reviews and answering questions. Nobody bills you for that, and it does not appear in any comparison, but it is the reason a project can be affordable on paper and undeliverable in practice.
What happens when it ends. Under a day rate you often keep nothing but decisions. Under a fixed fee you should keep the source code, the operational documentation and a trained internal owner, because the arrangement was built to finish. That difference is worth more than any rate gap, and it is rarely something a contract gives you by default.
The four questions that price it properly
Ask these before asking for a number. The answers tell you what you would actually be buying.
What ends the arrangement, and who can end it? A vendor who cannot describe the conditions of their own departure has not thought about it, and you will be the one who has to.
What do I hold at the end? Source code, credentials, documentation, and at least one person internally who can change things without calling. If the answer is vague, the real price includes a dependency nobody quoted.
Which decisions are yours and which are mine? Technology leadership means saying no to requests, including requests from people senior to the person saying no. Whether the vendor can do that, and whether you will back them, decides whether the arrangement works at all.
What is the smallest paid piece of work that would tell me whether this is right? If the answer is a large first engagement, that is information. A vendor confident in the fit will happily start small.
What we do, and why
We price the delivery on a fixed fee and the leadership on a bounded commitment with a written end. We do not sell open-ended day rates, and the reason is not principle: it is that we have watched them turn into a habit on both sides, where the client stops asking whether they still need the arrangement and the vendor stops asking whether they are still adding anything.
The one price we publish is the entry point. A short assessment, two to three thousand euros before tax, deducted if we continue, and the document is yours whether or not we do. That is deliberately small enough to be a test rather than a decision, which is what a first engagement should be. The technical due diligence page describes what it contains.
Further reading
- Fractional CTO, interim CTO, or consultant: the roles, before the pricing
- Fixed fee or time and materials: what each model makes a vendor optimise for
- Who owns the code your contractor writes: what you hold when it ends
- The exit clause you negotiate before you need it: how to keep an arrangement renegotiable
- Fractional CTO service: how we run it in practice