Fractional CTO or Development Agency? A Decision Table
These two get compared because they cost about the same. They are not alternatives. One supplies decisions, the other supplies hands, and buying the wrong one is expensive in a way that takes about six months to become visible.
Sep 8, 2026
A founder with a product to build and no technical co-founder gets two recommendations from two advisers in the same week. Hire a fractional CTO. Hire an agency.
They sound like competing answers to one question. They are answers to two different questions, and the reason the choice feels hard is that the monthly invoice can look similar.
The two problems people confuse
Missing capacity. You know what to build, you know roughly how, and there is nobody to build it. This is a supply problem. An agency, a contractor, or a hire solves it.
Missing leadership. Someone is building, or could be, but nobody senior enough is deciding what gets built, what it should cost, what happens when it breaks, and what to refuse. This is a judgement problem. A fractional CTO solves it.
The trap is that missing leadership presents as missing capacity. The team feels slow, the roadmap keeps slipping, and the obvious conclusion is that you need more people. So you buy more hands, point them at an undecided roadmap, and now the unmade decisions have more code built on top of them.
If you take one thing from this: work out which of the two you have before you look at suppliers, because both suppliers will tell you they can help.
The decision table
| Fractional CTO | Development agency | |
|---|---|---|
| What you are buying | Decisions and accountability | Delivery capacity |
| Typical commitment | One to three days a month | A team, full time, for months |
| Owns | Architecture, spend, hiring bar, security posture, what not to build | Building the agreed scope, on time |
| Answers to | You, directly | A statement of work |
| Good when | Nobody senior is deciding | The decisions are made and you need hands |
| Bad when | You need forty hours a week of execution | Nobody on your side can evaluate the output |
| Fails by | Being too thinly engaged to matter | Building exactly what you asked for |
| Ends when | You hire a full-time CTO, or the gap closes | The scope ships |
The row worth reading twice is the failure mode. An agency's characteristic failure is not incompetence. It is building precisely what the statement of work described, on time and to spec, and delivering something that does not serve the business, because nobody on your side had the standing to say "that requirement is wrong". Agencies are not paid to refuse the brief. That is somebody else's job, and if the job is vacant it does not get done.
When you need both at once
This is more common than either supplier will volunteer, and it is a perfectly good arrangement: the agency builds, the fractional CTO holds them to a standard your own team would if you had one.
That means architecture review before the approach is locked rather than after. Code and repository ownership in your name, in writing. A handover that actually works, tested by someone doing it rather than promised in a clause. And an independent read on whether what came back is what you needed.
Two conditions make it work. The fractional CTO must not be selling you the agency, or supplying it themselves, because independence is the entire value. And both sides need to know the arrangement from day one. A senior reviewer introduced in month four, unannounced, reads as distrust and gets treated accordingly.
The failure mode of each, in more detail
A fractional CTO fails by being decorative. Half a day a month, a call that becomes a status update, a title on a pitch deck. Below roughly one day a month you have an adviser, not a leader, and advisers do not own outcomes. Test for it: are decisions actually being made and recorded, or is the meeting a summary of what already happened?
An agency fails by succeeding at the wrong thing. On time, on budget, on spec, and the thing does not fit how the business works. The other version is the slower one: a codebase you cannot take elsewhere. If the repository is not in your name and the contract does not assign you the rights, you are renting your own production system, and no other supplier can legally take it over. That is the single most important clause to check, and it is checked far less often than it should be.
When the answer is neither
Some situations need something else, and saying so early is cheaper than discovering it in month three.
You need one senior engineer, permanently. If the work is continuous and technical rather than episodic and strategic, hire. A fractional arrangement is not a discount on a salary.
You have a capable, empowered head of engineering already. Then leadership is not the gap. If something still feels wrong, a fixed-scope technical review will tell you what it is more cheaply than any ongoing arrangement.
The software already exists and nobody can safely change it. That is a takeover, not a build. It has its own process and its own fixed price, and starting it as a new build throws away work you have already paid for.
An off-the-shelf product does the job. Buy the product. Any supplier who cannot name the products that compete with building it is either not paying attention or hoping you are not.
How to decide in one question
Ask: if a significant technical decision had to be made this week, who would make it, and would you trust it?
If there is a name and the answer is yes, you have leadership and you may need capacity. If there is no name, or the name is yours and you are not technical, no amount of delivery capacity will fix that, and adding it will make the eventual correction more expensive.
We work as a fractional CTO and we also build, and we keep those as separate agreements on purpose, because a fractional CTO who quietly becomes a sales channel for their own build team is no longer giving you independent advice.
If you are not sure which of the two you need, that is a reasonable thing to be unsure about and a short conversation usually settles it. Where the situation is genuinely unclear we tend to start with a fixed-scope technical review and let the findings define the arrangement, which is a cheaper way to find out than committing to either.