Fractional CTO vs agency: which should you hire to build your product?

A fractional CTO and an agency differ most in whose side each one is on. A software agency sells delivery: a team that builds what you specify, billed by the hour or per project. A fractional CTO is your own part-time technology lead, paid to decide what is worth building and to check the work. Many founders need both.

Think of a building contractor and the architect who signs off on the work for you. One has the crew. The other knows whether the crew is building the right thing, the right way, at a fair price. New to the role? Read my explainer on the fractional CTO model first.

Fractional CTO vs agency at a glance

On paper they look like rivals, but mostly they do different jobs. The exception is a hands-on fractional CTO who also builds, which can replace an agency outright for an early product.

Whose side is each one on?

An agency earns money by selling hours or projects. That isn't a criticism; it's the model, and plenty of agencies do honest, excellent work. But the model shapes behavior.

On a time-and-materials contract, more hours mean more revenue, so nobody at the agency is paid to tell you a feature isn't worth building. On a fixed-price contract the incentive flips: the agency protects its margin by building exactly what the spec says and pricing everything else as a change request. Neither is dishonest. Both put the agency on the other side of the invoice. I compare the two contract types in fixed price vs time and materials.

A fractional CTO is paid to represent you, so you hear the advice a vendor is rarely in a position to give:

• Use an off-the-shelf tool for this instead of building it.
• Cut these three features from the first release.
• Don't approve that change request; it was in the original brief.
• Hire your own developer next year instead of renewing the contract.

To be fair, a fractional CTO has incentives too. A retainer rewards staying engaged, and some fractional CTOs push a favorite stack or let you become dependent on them. The protection is the same as with an agency: written deliverables, real documentation and every account in your company's name.

Who checks the quality of the work?

If you aren't technical, you can judge an agency only through demos and deadlines. Demos show the happy path, not what's underneath, such as:

• Hard-coded data that looks real until a real customer signs up
• No automated tests, so each new feature can quietly break an old one
• Weak security basics: passwords in the code, an admin panel open to the internet, backups nobody has tested
• An architecture that copes with 100 users and struggles at 10,000
• Cloud bills that grow faster than your customer count

Good agencies have senior engineers who review code internally. It's still the vendor checking its own work, though, and when a deadline gets tight, internal review is in my experience often the first thing to slip.

A fractional CTO reviews the work as your representative: reading pull requests, testing on a staging environment with realistic data, checking the infrastructure and asking why things were built that way. The point isn't to catch the agency out. It's to find problems in week three, when they cost an afternoon, rather than in month nine, when they cost a rebuild.

Who owns the code, the accounts and the knowledge?

Three kinds of ownership matter, and agencies handle each one differently:

• The code itself. Your contract should assign the intellectual property to your company. Many agency contracts transfer it only on final payment, which matters if the relationship ends early. Ownership rules differ between countries and none of this is legal advice, so get a lawyer to read the contract before you sign. There's more in who owns the code when you outsource.
• The accounts. Repository, cloud hosting, domain, app store listings, payment provider, analytics. Agencies sometimes create these under their own logins to move faster. That's harmless until the day you want to leave.
• The knowledge. Why the database is shaped the way it is, which shortcuts were taken, what breaks if someone touches billing. It lives in the agency team's heads, documentation is often thin because nobody budgeted for it, and people rotate between clients.

Part of a fractional CTO's job is keeping all three with you: accounts opened in your company's name from day one, decisions written down, and enough documentation that a new developer could pick up the work. That turns switching vendors, or bringing development in-house, into a decision rather than a crisis.

Is a fractional CTO cheaper than an agency?

They price different things, so compare budgets, not rates.

An agency's price covers a ready-made team plus everything around it: project management, sales, office and margin. That has real value. Rates vary enormously by market. In my experience, agencies in the US often bill around $100 to $200 or more an hour, while rates in many offshore markets are a fraction of that. A first version of a product commonly runs into the tens of thousands of dollars and can go well into six figures, depending on scope.

Fractional CTOs mostly charge a monthly retainer. Depending on how many days a week you buy and whether the CTO also builds, expect anything from the low thousands to upward of $20,000 a month. I break down the models and ranges in what a fractional CTO costs.

The realistic budgets look like this:

• Agency alone: the quote, plus change requests, plus whatever it costs to fix problems nobody caught.
• Fractional CTO plus agency: the retainer plus an agency budget that is often smaller, because the scope is tighter and the brief clearer.
• Hands-on fractional CTO alone: one retainer covering leadership and much of the build. Often cheaper for an early product, but one person sets the pace.

Say you run a group of fitness studios and want a booking app. One agency quotes $40,000 and 12 weeks; another quotes $120,000 and six months. Neither is necessarily wrong. They are almost certainly assuming different things about payments, admin tools, integrations and testing. Without someone technical on your side, you'll probably choose on price, or on how much you liked the salesperson. A few days of CTO time spent writing one scope that both agencies quote against is often the best money in the whole project.

When an agency is the right call

An agency on its own, with no fractional CTO, is a good choice in these situations:

• You already have technical leadership. A CTO, technical co-founder or senior engineer on your side can brief the agency, review the code and push back. You don't need another leader; you need capacity.
• The project is well defined and bounded. A marketing site, a known integration, a rebuild of an existing system with a clear spec, a second app on a platform you already run. When the “what” is settled, the risk is in execution, and execution is what agencies are built for.
• You need a full team fast. If a launch date is fixed and you need design, frontend, backend and QA working in parallel next month, an agency can staff that in a way one person can't.
• You need specialist depth. Games, 3D and AR, hardware and embedded software, or deep experience in a regulated industry. A specialist that has built ten of these will usually beat a generalist.
• Software isn't your core business. For an internal tool at a company with a capable IT lead, a clear brief and a good agency are often simpler than adding a part-time executive.

The flip side: a fractional CTO is the wrong hire if all you need is a brochure website, if you already have a strong CTO, or if your only problem is capacity. For picking the agency itself, see how to choose a software development agency.

When a fractional CTO is the smarter first hire

• You aren't technical, and the software is the business rather than a side project.
• You aren't yet sure what the first version should include. Working that out on an agency's clock is expensive.
• You have quotes that differ by a factor of three and no way to judge them.
• You plan to hire your own team within a year or two and want the architecture and handover planned from the start.
• Investors or a large customer are about to ask technical questions you can't answer.
• An agency build has stalled, or shipped and was never maintained. Sorting that out is a core part of my work. The right first moves are to secure the code and accounts, then audit what is really there. I've written up the rescue playbook for stalled builds separately.

How a fractional CTO and an agency work together

You get the agency's capacity with someone on your side steering it. A typical split:

In practice it runs in five stages:

1. Scope before quotes. The CTO turns your idea into a written scope and a rough architecture, so every agency prices the same thing.
2. Selection. Shortlisting, reading proposals, checking live products and meeting the people who will actually do the work.
3. Setup. Repository, cloud and app store accounts created in your name, with the agency invited in.
4. Delivery. A demo on a staging environment every week or two, review of every pull request, and a short plain-English update for you.
5. Exit. Documentation and a handover plan, whether the next step is a new phase, a new vendor or your own team.

Good agencies tend to welcome this. A technical client writes clearer briefs, argues less about scope and signs off faster. If an agency resists giving your CTO access to the code, take note.

My own setup is a variation: I take the CTO seat and build the product myself, which for many early products removes the need for an agency at all. Once the work needs more than one person, I hire the extra people and manage them, along with any outside vendors, on the founder's behalf. You can see what my fractional CTO service includes.

So which should you choose?

• Technical leadership in place and a clear scope: hire a good agency and skip the fractional CTO.
• No technical leadership and a fuzzy scope: start with a fractional CTO, then decide whether the build needs an agency, a few developers or just the CTO.
• An agency already building and a nagging feeling: get a fractional CTO to review the code and process before the next large invoice.
• A small, early product: a hands-on fractional CTO may be able to build it without an agency.