When a Senior Dev Isn't Enough
A few weeks ago, a founder reached out to me: just a small team, six engineers, AI feature in production, growing fast. Something that we see a lot these days. They had a senior dev who was great. Genuinely great. The kind of engineer who was able to answer complex questions and never backed down from a challenge.
The problem was that there was no challenge there for him. The decisions piling up were not coding decisions.
Should they migrate from one model provider to another? Should they build their own retrieval layer or use a managed one? Should they self-host the vector database or stay on a SaaS? How should they handle data residency for European customers? What was the right approach to evaluation? When did "good enough" mean ship, and when did it mean keep iterating? The senior dev had opinions on all of these, but they were engineering opinions, not strategic ones. He could tell you how to do something three different ways. He couldn't tell you which one was the right call for the business, because that wasn't his job, and it wasn't fair to ask him to make it his job.
In fact, several times along my career, I was that dev. If you don’t know where you want to go, any road is good enough.
That's where a fractional CTO starts to act in an AI project. When there’s a need to make decisions that are business-oriented.
What a fractional CTO actually does
The title sounds like a watered-down version of a full-time CTO. But it's in fact a different role, with a different shape.
A full-time CTO owns the technology. They hire, they fire, they set the roadmap, they sit in the leadership meetings, they're accountable for outcomes over the long arc of the company. A fractional CTO doesn't do any of that, and shouldn't. The role is closer to a senior advisor with implementation authority on specific decisions.
For an AI project specifically, the work clusters around five things.
Decisions that need engineering depth and business context simultaneously. Should you build or buy? Should you optimize for speed or accuracy on this use case? How much should you spend on infrastructure now vs. how much should you defer? These are not the senior dev's call, and they're not the founder's call either, because the founder doesn't have the technical context to evaluate the trade-offs.
Architecture decisions with long-tail consequences. What you decide about your vector store, your prompt management, your evaluation infrastructure, and your observability now will determine what's possible (and what's expensive) eighteen months from now. Small teams routinely make these decisions in a sprint planning meeting and pay for them for years. A fractional CTO is the person who looks at the proposed architecture and asks the questions nobody on the team is senior enough to ask.
Translation between the team and the rest of the business. A founder asks "can we add this feature?" The senior dev says "yes, but it'll take three weeks." The fractional CTO is the person who says "yes, three weeks of build time, but it requires us to change the retrieval layer, which will affect every other feature, and the right sequence is to do these two other things first." That kind of translation is what most teams don't have, and most stuck projects need.
Hiring decisions for AI-specific roles. What does a good ML engineer look like, vs. a good infrastructure engineer who happens to know LLM APIs? When do you need a dedicated evaluation engineer? When is your existing team enough, and you just need to give them air cover? These are calls that small teams routinely get wrong because they hire what they think they need based on the job descriptions they've seen.
A second opinion that's not on the payroll. The senior dev on the team has career incentives. Saying "I don't know how to do this" or "I'm worried we made the wrong call six months ago" is harder when you're trying to keep your job. A fractional CTO has no such incentive. Challenge the team and the management is part of the job description.
What a fractional CTO is not
Not a coder. If the engagement turns into shipping features, the fractional CTO is being misused, and the team is paying senior consulting rates for work a mid-level engineer should do.
Not a project manager. Fractional CTOs who turn into project managers are signaling that the team has a huge leadership gap that needs to be addressed. If the team needs a PM, hire a PM. They cost less, and they're better at it.
Not a salesperson. Some fractional CTOs are essentially the technical face of a consulting agency, there to upsell more services. If your fractional CTO is constantly recommending external vendors, especially ones they have a relationship with, that's a conflict of interest worth examining.
Not a permanent solution. The good ones work themselves out of the role within twelve to eighteen months, either by helping you hire a full-time CTO or by leaving the team in a position where they don't need one yet. Anyone who's been a fractional CTO at the same small company for three years is no longer fractional.
When you need a Fractional CTO
Most early-stage companies do not need a fractional CTO. They need senior engineers and a founder who can make decisions. Adding a fractional CTO on top of that is an overhead that simply doesn't pay for itself.
You start needing one when these things become true at the same time:
- The AI part of your product is critical enough that getting it wrong costs you customers, money, or worse, both.
- Your senior engineers are excellent, but they're not the right people to make strategic technology decisions, either because they don't have the experience or because making those decisions is not what you hired them to do.
- You're not ready to commit to a full-time CTO yet, either because you can't afford one, because the company isn't at the stage where that role makes sense, or because you haven't met the right person.
- You have decisions that are actively blocking the team, and the cost of making the wrong one is higher than the cost of getting outside help.
If two of those four are true, you can probably get by with occasional advisory calls. If three or four are true, a fractional CTO arrangement is almost mandatory.
If none of them are true, you don't need a fractional CTO. Use that money on things that will make your actual devs happier.
What the engagement looks like in practice
Most of my fractional CTO engagements run two days a week, sometimes three during heavier periods. The work splits roughly into three buckets.
Strategic time. Architecture reviews, build-vs-buy decisions, evaluation of options, and written recommendations that the team can refer to later. This is the most visible part of the work and the part that founders usually expect.
Team time. One-on-ones with senior engineers. Reviewing pull requests on the strategically important parts of the system. Pairing on hard problems when it would teach the team something. Pushing back on the team's instinct to over-engineer or under-engineer specific things. A team that gets six months of weekly pushback from a thoughtful outsider is a meaningfully better team at the end of those six months, regardless of what got shipped.
Leadership time. Sitting in on board meetings when AI-related decisions are on the table. Writing the technical sections of investor updates so the founder doesn't have to. Helping draft job descriptions, interview rubrics, and offer levels for technical hires. Being the person the founder calls when they get an offer to integrate with a vendor and need someone to read the contract with an engineering eye. This part is less visible but often where the most value gets created.
The split varies. Some engagements are 80% strategy and 20% team. Others are the reverse. The shape of the engagement should follow what the company actually needs, instead of a fixed template.
How much does a fractional CTO cost?
I'm going to say something that most consultants won’t: Fractional CTO work is priced higher per hour than build work, and the value isn't always obvious in the first month. You're paying for judgment, for the absence of mistakes you didn't make, and for the existence of a relationship that lets you call someone when you need them. None of those show up cleanly on a deliverables list.
This means the engagement only works when the company is at a stage where the cost of bad decisions is high enough to justify the cost of getting them right. Pre-product-market-fit, you're better off using that money to hire another engineer. Post-traction, when the wrong architecture call could cost you six months of refactoring, the math flips.
A useful test: if your senior engineer made a decision tomorrow that turned out to be wrong, would the cost of the mistake be more or less than three months of fractional CTO fees? If it's less, you don't need this yet.
How this fits with the rest of your AI investment
A fractional CTO is not a substitute for the work covered in the post about hiring an AI consultant for a specific build, or for the post about why your prompts aren't the problem. Those are scoped engagements with deliverables.
The companies I've seen do this well use all three at different times. They bring in a consultant to build the first version. They bring in an architect when the first version stops working. They bring in a fractional CTO when the team is large enough to need leadership and small enough that a full-time hire doesn't make sense yet. Three different needs, three different engagements.
If you're at the stage where strategic decisions are piling up faster than your team can make them well, and you can't justify a full-time CTO yet, that's the engagement I take on. Two days a week, a written scope, defined exit. The goal is to leave you in a position where you don't need me anymore.