What does a fractional CTO actually do that a senior developer doesn't?

A fractional CTO makes and owns technical decisions rather than executing them: choosing the architecture, deciding what to build versus buy, evaluating vendors and build partners, sizing technical risk for a board or an acquirer, and telling you when someone you're already paying is doing bad work. A senior developer produces software. A fractional CTO produces decisions and judgment, and often does not write the production code at all.

Do I need a fractional CTO before I hire an agency or a freelancer?

Only if you cannot evaluate the work yourself. If nobody on your side can tell a reasonable architecture from an unreasonable one, or a real estimate from a padded one, you are buying execution blind and some form of technical leadership is worth the money. If you or someone on your team is technical enough to make those calls, the leadership layer is overhead and you should go straight to execution.

Can the same person be both my fractional CTO and my developer?

Yes, and for small teams it is often the most efficient shape — a technical builder who makes the architecture calls and then implements them removes the translation layer between decision and code entirely. The tradeoff is that you lose independent review: the person grading the work is the person doing it. That is acceptable when the relationship is small and the code is yours to audit; it is not acceptable when you specifically need an outside opinion on an existing vendor.

Why is a fractional CTO priced as a retainer and a build priced per project?

Because the value is shaped differently. Leadership is ongoing and unpredictable in timing — the decisions arrive when they arrive, and you are paying for availability and accumulated context. A build has a defined end state, so it can be scoped, quoted, and finished. Conflating the two is how founders end up paying a monthly retainer for what was really a one-time build, or trying to cram years of ongoing technical guidance into a fixed-bid project that ends the day the code ships.

Fractional CTO vs. agency vs. freelance developer: which do you actually need?

A fractional CTO sells technical judgment. An agency and a freelancer sell execution. Here's how to tell which one your situation calls for — and when one person can honestly be both.

The distinction nobody explains before you're already spending money

Founders usually arrive at this question in the wrong shape. They open three tabs — a fractional CTO's site, an agency's site, a freelancer's profile — and try to compare them the way you'd compare three quotes for a new roof. But two of those tabs are selling the same thing and the third is selling something categorically different, which is why the comparison feels slippery and why the prices don't line up.

Here is the actual line. An agency and a freelancer sell execution. Someone builds the thing. The deliverable is working software. A fractional CTO sells judgment. Nobody necessarily builds anything. The deliverable is a set of decisions: this architecture and not that one, this vendor and not that one, this hire before that hire, this risk is real and that one is theatre.

You can hire all three. You can hire one. What you cannot do is hire a fractional CTO and be surprised that no product appeared, or hire an agency and be surprised that nobody told you your data model was going to hurt in eighteen months. Those are different purchases.

	Fractional CTO	Agency	Freelance developer
What you're buying	Technical decisions and judgment	Delivery capacity across multiple people	One person's build throughput
Primary deliverable	Architecture calls, vendor selection, hiring plan, diligence answers	Shipped software, on a plan	Shipped software, scoped tightly
Writes production code	Sometimes, often not	Yes, by a team you may not meet	Yes, by the person you talked to
Commitment shape	Ongoing retainer, months to years	Project or retainer with statements of work	Project or hourly, usually finite
Ends when	You hire a full-time CTO, or the decisions stop being hard	The scope is delivered	The scope is delivered
Fails you when	You needed a product and got a strategy deck	Nobody senior on your side can evaluate the work	The work outgrows one person

The word "fractional" is doing a lot of work in that first column, and it's worth being precise about it: fractional means a fraction of a full-time role, not a fraction of the seniority. You're renting a slice of someone's week who would otherwise be a full-time CTO somewhere. That's why the pricing shape is a retainer — you're buying availability and accumulated context, not output.

When you genuinely need a fractional CTO

You're a non-technical founder about to spend real money on a build. This is the clearest case. You have a business you understand perfectly and a product you can describe in outcomes but not in systems. Somebody is about to quote you a number for building it. You have no way to tell whether that number is fair, whether the approach they described is sensible, or whether the thing they deliver in four months will be maintainable by anyone else on earth. That asymmetry is expensive. A fractional CTO closes it — not by building anything, but by sitting on the other side of the table when the build partner talks.

The specific work here is unglamorous and high-leverage: reading a proposal and spotting what's missing, asking why the vendor chose a stack, insisting on who owns the repository and the cloud accounts, defining what "done" means before anyone starts, and reviewing progress in a way that isn't just watching a demo and nodding. Most non-technical founders don't get burned because their developer was malicious. They get burned because nobody was checking, and by the time the problems surfaced, they'd paid for six months of the wrong foundation.

You're raising, and technical credibility is part of the round. Investors ask technical questions. Not deep ones, usually, but pointed ones: is this defensible, what happens at 100x the current load, how much of this is your IP versus an API you're reselling, what happens if that API triples its price. A founder who answers those with "I'd have to ask my developer" is answering badly, and the answer costs valuation. A fractional CTO prepares you for those conversations and, in a real diligence process, answers them directly. This is also true in reverse — if you're acquiring something, or evaluating a partnership with a technical dependency, someone needs to look under the hood on your behalf.

The technical decisions matter more than the immediate build. Some products are architecturally boring and the only question is who types fastest. Others have one or two decisions that determine everything downstream: how the data model handles multi-tenancy, whether you're on someone else's platform or your own, whether compliance was designed in or bolted on. When your situation has a decision like that in it, the value of getting it right dwarfs the cost of the leadership layer. Getting it wrong is not a bug you fix later; it's a rewrite.

You already have developers and can't tell if they're any good. This is the case people are most embarrassed to say out loud. You have a team, or an agency, or an inherited codebase, and something feels off — velocity is slow, estimates keep sliding, every small change breaks something else — but you have no basis for judgment. An outside technical read is exactly what a fractional engagement is for, and it's a legitimate reason to hire one for a short, defined period rather than an open-ended retainer.

When you can skip the leadership layer entirely

Someone on your side is already technical enough. If you're a technical founder, or you have a competent engineer on staff who can hold the architecture in their head, a fractional CTO is a layer of overhead that duplicates a judgment you already have. Go straight to execution. Hire the freelancer or the agency, review the work yourself, and spend the money you saved on more building.

The honest test isn't credentials, it's this: can you look at a proposed approach and articulate why you'd choose it over the obvious alternative? Not "does it sound reasonable" — can you name the tradeoff? If yes, you're the technical decision-maker and you don't need to rent one.

The scope is genuinely small and finite. A marketing site, an internal tool, a single integration, a prototype meant to test one hypothesis and then be thrown away. Adding a strategic leadership relationship to a four-week build is a category error. The strategy for a four-week build is: build it, learn the thing, decide later.

The decisions have already been made, correctly. If you're on an established stack, extending a system that already works, and the remaining questions are "how" rather than "whether," you need hands, not opinions.

You'd be paying for advice you have no capacity to act on. This one catches early-stage teams. A fractional CTO produces recommendations, and recommendations create work. If your entire technical capacity is one part-time contractor, a strategic roadmap you can't staff isn't leverage — it's a document that makes you feel behind. Buy execution until you have enough of it that coordinating it becomes the hard part.

The fourth option the title leaves out

The three-way framing assumes leadership and execution come from different people. Often they should — a large team needs a decision-maker who isn't buried in a branch, and an independent reviewer can't be the person being reviewed.

But at the size most founders are actually operating at, the split creates its own cost. Every architectural decision has to be transmitted from the person who made it to the person implementing it, and transmission loses fidelity. The fractional CTO writes a document. The developer reads it, interprets it, hits a case the document didn't anticipate, and makes a call. Multiply that by a few hundred decisions and the thing you get is not the thing that was designed.

The alternative is a technical builder who does both — makes the architecture calls and then writes the code that implements them. That's the model this studio runs on, and it's worth naming plainly rather than pretending it's one of the three: the decision and the implementation happen in the same head, so nothing is lost between them. When a design assumption turns out to be wrong in week three, it gets revised by the person who made it, immediately, instead of becoming a change request.

What you give up is real and I'd rather say it than hide it. You lose independent review — the person grading the work is the person doing it, and that's a genuine conflict when what you specifically wanted was an outside opinion. You lose bench depth, which is the standing argument for agencies and doesn't go away here (the freelancer vs. agency comparison covers that tradeoff in detail). And you lose the option of pointing at someone else when it goes wrong.

So the combined model fits when you want decisions and code from one relationship and are comfortable auditing the output yourself or with a third party. It does not fit when the entire job is "tell me whether my current vendor is ripping me off." For that, hire someone with no stake in the answer.

A decision framework that actually resolves

Two axes. Your technical background, and what the situation needs.

If you're non-technical:

Need leadership only — you have a team or a vendor already, but no judgment layer. Fractional CTO, ideally on a short defined engagement first.
Need execution only — this is rarely true, and believing it is true is the most common expensive mistake. If you can't evaluate the work, you're not buying execution, you're buying hope. Either add a leadership layer or hire a builder you trust enough to hand the decisions to, deliberately and with eyes open.
Need both — either a fractional CTO plus a separate build partner, or one technical builder who does both. Choose the split if the build is big enough to need several people; choose the combined shape if it's one person's worth of work anyway.

If you're semi-technical — you can read code, you've shipped something, but you haven't made architecture decisions at scale:

Need leadership only — you probably need a sounding board more than a CTO. A short advisory engagement, or a technical review at specific milestones, beats an ongoing retainer.
Need execution only — go straight to a freelancer or agency. You can evaluate the work well enough.
Need both — the combined builder is usually the best value here. You can hold the vendor accountable, so you don't need a third party to do it for you.

If you're technical:

Need leadership only — you don't. You might need a peer to argue with, which is a different and much cheaper purchase.
Need execution only — agency for parallel workstreams, freelancer or solo studio for depth on one thing. This is the app development shape.
Need both — you need capacity, not leadership. Hire builders.

The framework fails in one common case worth flagging: founders who are technical in a different domain. A hardware engineer, a data scientist, a technical person from a large company who has never owned a full stack. That looks like "technical" on the grid but behaves like "semi-technical," because domain fluency doesn't transfer as far as it feels like it should.

Cost shape matters more than cost level

The most expensive mistake in this whole comparison isn't picking the wrong option. It's picking the right option with the wrong commitment structure.

A fractional CTO is priced as an ongoing retainer because the value is ongoing and unpredictable in timing. You are not buying a deliverable; you're buying availability, accumulated context, and someone who already knows your system when the decision arrives. That structure makes sense when decisions keep arriving. It stops making sense the moment they don't — and the failure mode is a retainer that quietly renews for months after the hard calls are behind you, buying you a monthly check-in you don't need.

A build is priced per project, or per day, because it has an end state. It can be scoped, quoted, and finished. That structure makes sense when you know what you want. Its failure mode is the opposite: trying to buy ongoing technical guidance inside a fixed-bid project, so the relationship ends the day the code ships and there's nobody to ask when reality arrives three weeks later.

Two concrete symptoms to watch for. If you're paying a retainer and your last three sessions were status updates rather than decisions, you're paying leadership prices for account management — convert it to on-call or end it. If you're on your fourth change order and each one required re-explaining the business context from scratch, you bought project pricing for what is actually an ongoing relationship, and you're paying the setup cost every time.

Neither is a pricing negotiation. They're structural mismatches, and no rate adjustment fixes them. Get the shape right first, then talk about the number.

The short version

If you can't evaluate technical work and you're about to spend serious money on it, buy judgment before you buy code. If you can evaluate it, buy code and skip the layer. If the work is one person's worth and you'd rather not run two relationships, look for a builder who does both and go in clear-eyed about the review you're giving up.

And whichever you pick, match the commitment shape to the work: retainers for decisions that keep coming, project pricing for things that finish.