Every founder who calls me starts the same way: "What's your fee?" It's the wrong first question, and answering it directly usually leads to a worse deal for both sides.
The number moves with scope, stage, and vertical. I've written about the actual ranges elsewhere on this site, in detail, with the drivers that push a fee up or down. That's not what this piece is about. This piece is about the question underneath the question: what structure are you actually buying, and does it match the shape of the work you have?
There are three structures on the market. They are not interchangeable, and picking the wrong one costs more than picking the wrong number.
The three structures, and who carries the risk in each
Retainer. A fixed monthly fee for a fixed weekly time commitment, usually one or two days a week. You get predictability: same invoice every month, same availability every week. The CTO gets flexibility: the fee doesn't change if your priorities shift mid-month, and it doesn't change if a sprint runs long. This is the right structure when the work is ongoing and the scope is fuzzy by design, things like technical leadership, architecture ownership, team management, vendor decisions. You're not buying a deliverable. You're buying a standing capability.
Hourly. You pay for time actually spent, tracked and invoiced. You get flexibility: scale up in a crunch week, scale down when things are quiet, no minimum commitment. The CTO carries the unpredictability: income varies week to week, and there's no guaranteed floor. This structure fits short, bounded engagements: a single architecture review, a due diligence sprint, a specific technical decision that needs an outside eye once. It's a poor fit for ongoing leadership, because hourly billing creates an incentive to bill hours rather than to make the fast call that ends the problem in twenty minutes.
Project-based. A fixed price for a fixed, scoped outcome, agreed before work starts. This only works when the outcome really is fixed: a security audit with a defined checklist, a migration with a defined end state, a technical due diligence report with a defined deliverable. The risk sits with whoever wrote the scope. If the scope is vague, project pricing turns into a fight over what counts as "done," and that fight is worse than any hourly rate disagreement, because now there's a written number both sides are anchored to.
Why "what's the fee" skips the real decision
When a founder leads with fee, they're usually trying to compare apples to apples across a few candidates. That's reasonable. But two CTOs quoting the same monthly number on different structures are not offering the same thing.
A CTO quoting a retainer for two days a week is committing standing availability against your roadmap, whatever it turns out to be. A CTO quoting the same monthly figure as an hourly cap is committing to stop working once the hours run out, mid-crisis if that's when the cap hits. Same number, completely different risk profile.
The better opening question is: "given what I need done over the next quarter, which structure fits, and what does that structure typically cost?" That question forces you to articulate the work first. Most founders haven't done that yet when they ask about fee, which is exactly why the fee conversation goes nowhere useful.
A short diagnostic
Ask yourself these before you ask anyone their rate:
- Is the work ongoing or bounded? Ongoing leadership wants a retainer. A single audit or review wants hourly or project.
- Do you know the end state precisely enough to write it down? If yes, project-based is available to you. If you can't describe "done," project pricing will hurt you.
- Does your need fluctuate week to week? If it's genuinely lumpy, hourly protects you from paying for a quiet month. If it's steady, hourly just adds accounting overhead for no benefit.
- Who should carry the risk of scope creep? Retainers push that risk onto the CTO's time allocation. Hourly pushes it onto your budget. Project-based pushes it onto whoever scoped it, which is why the scoping document matters more than the number attached to it.
The honest caveat
None of this means the number doesn't matter. It does, and it should be part of the decision. But asking for the number before you've picked the structure is like asking a landlord for the rent before you've said whether you want a studio or a three-bedroom. The answer will be a number. It just won't be useful.
Need help thinking this through? Book a 30-min call — no pitch. Book a Free 30-Min Strategy Call →
