What Is a Fractional CTO? A Guide From a Working CTO

A fractional CTO is a senior technical leader who works for your company part-time, usually somewhere between a few hours a week and two days. They make the calls a CTO makes: what to build and in what order, how it gets built, who to hire, and what to tell investors and customers when they ask about security. You pay for that judgment by the hour or by the month, instead of with a full-time salary and a large slice of equity.

You're renting judgment, not headcount.

I'm CTO at Hexis, I led Emblem's platform as CTO, and I do fractional CTO work through Pulore. I've been building software for more than 15 years, at Verizon Media, Danske Bank and ISSUU among others. This guide is what I tell founders who ask whether they need one. The market figures are sourced and dated. The rest comes from doing the job.

What a fractional CTO actually does

The title is vague, so here's the work, by stage. "Part-time CTO", "virtual CTO" and "CTO as a service" mean the same thing.

Before you have engineers

Founders at this stage are often about to hand a budget to an agency or a freelancer, without a way to judge the proposal. The work:

• Scope the first version. Cut the feature list down to what tests the business, and write down what's out, so it stays out.
• Pick the stack and the build partner. Read the proposals, ask the questions an engineer would ask, and say plainly which risks you're taking on.
• Own the keys. The company should own the GitHub organization, the cloud accounts, the domain and the app store accounts from day one, not the agency. Getting them back after a falling-out is slow, and sometimes impossible.
• Review the work as it lands. A weekly look at the code and the demo catches drift while it's still cheap to fix.

With a small team

With two to six engineers, the job moves from choosing to steering:

• Architecture decisions, written down. What we chose, what we rejected and why. A one-page decision record outlives a meeting nobody remembers.
• Hiring. The job description, a technical interview that tests the work the job needs, and the debrief.
• How the team ships. Code review, CI, deploys, on-call, and a release rhythm people can plan around.
• Security basics before anyone asks. Single sign-on, least-privilege access, secrets out of the repo, and backups that have been restored at least once.
• The cloud bill. Someone has to read it.

When customers, auditors and investors start asking

• Security questionnaires and SOC 2. Enterprise customers send long spreadsheets of security questions, and the answers have to be true. At Hexis I'm leading the SOC 2 audit, which is in progress.
• Technical due diligence, on either side of the table: preparing for an investor's review, or doing one for an investor.
• Hiring your full-time CTO or VP of Engineering, then handing over.

At Hexis I lead four engineers. We re-architected the platform, which now runs PostgreSQL in three writable regions on Google Cloud, while the product grew ARR by more than 300%. Most of that job is the list above, plus code.

Fractional, interim, full-time or an agency?

These get mixed up, and they solve different problems.

An agency builds what you ask for. A fractional CTO tells you what to ask for, and checks what comes back. You can have both, and plenty of early-stage companies should.

What a fractional CTO costs

There's no good survey of what fractional CTOs earn, and most rates you'll read online are someone's asking price. The most useful public data I found, checked on October 28, 2026:

The gap between the first two rows is the point. Candidates ask about $80 an hour more than companies post. Headlines like "$9,000 to $15,000 a month" are the asking side, at 15 hours a week.

The usual ways to pay:

• Hourly. You pay for what you use. Most fractional job posts are priced this way.
• A monthly retainer, for a set block such as a day a week. Easier to budget for, and it keeps the CTO available.
• A fixed price for one-off pieces: an architecture review, a code audit, technical due diligence.
• Equity, rarely, and nobody publishes how often. If it comes up, use advisor benchmarks like the FAST agreement, and vest it.

At Pulore, my fractional CTO time is $100 to $150 an hour, billed hourly. An architecture review and code audit is a fixed price from $5,000, and technical due diligence from $7,500. A day a week comes to about $3,500 to $5,200 a month, or $42,000 to $62,000 a year.

For comparison, Kruze Consulting's 2026 guide, built from its clients' payroll data, puts a seed-stage CTO's average cash pay at $155,000. That's before benefits, and a non-founder C-level hire's first equity grant is about 1% at the median, per Carta. A day a week of fractional time costs a quarter to two fifths of that salary, with no equity. The catch is that you get a day a week.

When you need one

• You're about to sign with an agency or a freelancer and can't judge the proposal.
• You're hiring your first engineers and can't interview them.
• An investor or an enterprise customer has sent technical or security questions you can't answer.
• The team ships slowly, and you can't tell whether it's the people, the process or the code.
• Someone has proposed a rewrite.
• The cloud bill keeps growing and nobody can explain why.

When you don't

• You have a strong technical cofounder. Give them the title, and an advisor if they want one.
• The technology is the company. Y Combinator, drawing on thousands of startups, says that companies without a technical cofounder underperform, and that hiring consultants doesn't fix it. A fractional CTO can bridge the gap while you look for one. It's a bridge, not the destination.
• You need someone in the room every day. Once decisions pile up between weekly calls, or you're in a crisis, part-time leadership becomes the bottleneck. Hire full-time.
• You need features built, not decisions made. Hire engineers, or an agency with a clear scope.
• You won't make time for it. A fractional CTO needs at least an hour a week of the founder's attention. Without it you're paying for reports nobody reads.

How to choose one

Ask these, and listen for specifics:

1. What have you run in production in the last two years? Titles age. Systems someone ran recently, and was paged for, don't.
2. Do you still write code? Someone who reads pull requests catches the problems a slide deck hides.
3. Can I see something you wrote? An architecture review, a decision record, a postmortem, with names removed. Writing is most of the job.
4. Who did you hire, and are they still there?
5. What happens when production breaks at 2am? Agree on availability in writing, before it matters.
6. Do you also sell development? If so, ask how they keep the advice separate from the sale. Pulore builds software too, so ask us the same question.

Red flags: a rewrite recommended before anyone has read the code, no written output after the first month, a long lock-in, or a request to hold your accounts in their name.

Put it in the contract

• The company owns the work. An IP assignment clause covers everything they write, design or decide for you.
• Accounts stay in the company's name. They get access, not ownership, to the repos, the cloud accounts and the domain.
• The exit is written down. What ends the engagement (a hire, a handover to the team, or a date), and the notice period. Without one, these arrangements tend to run on indefinitely.
• In the UK, check IR35. If your company counts as small, the contractor's own company decides their off-payroll status, not you. Ask your accountant either way.

How the first month goes

This is how I start, and most good fractional CTOs do something similar:

1. Access. Code, cloud accounts, docs, and conversations with the people who build and run the system.
2. Trace the critical paths. How data moves, how code gets to production, where the security gaps are, and what it all costs.
3. A written report with the risks ranked, and a call to walk through it.
4. The first plan. The report becomes the first set of decisions we agree on. After that: one call a week, a shared decision log, and reviews of designs and pull requests in between.

How it ends

A good engagement plans its own exit. The usual trigger is a team big enough that decisions need someone in the room every day, or a round that pays for a full-time CTO. Then the fractional CTO writes the job description, helps run the interviews and hands over the decision log, so the new hire doesn't start from zero. If the role got harder to hand over the longer it went on, the decisions weren't being written down.