Most companies do not fail on technology because of bad code. They fail because nobody owned the decisions: what to build, what to buy, who to hire, which shortcut was safe and which would cost a year. A chief technology officer owns those decisions. A fractional one owns them part-time.
I work as a fractional CTO, and I still write code. This is a plain account of what the role is, what it costs, where it goes wrong, and how to tell whether you need one.
What does a fractional CTO actually do?
The job is ownership of the technical side of the business, scaled to the hours available. In practice that means five things.
- Direction. What gets built first, what waits, and what never gets built.
- Architecture. How the system fits together, written down so the next engineer can follow it.
- Build or buy. Which problems deserve custom software and which are solved by a subscription.
- People and vendors. Interviewing engineers, reviewing agency proposals, and saying plainly whether an estimate is sound.
- Delivery. Making sure work ships, and stepping in where the risk is highest.
For an early-stage company the last point matters most. Advice with nobody to carry it out does not move a product forward.
How is it different from a full-time CTO, a consultant or an agency?
They solve different problems, and the confusion between them is expensive.
| Option | What you get | Best when |
|---|---|---|
| Full-time CTO | A leader for an engineering team, every day | You have engineers to lead and the budget for an executive |
| Fractional CTO | The same ownership, for part of the week | Decisions outrun the team, but a full-time hire is early |
| Consultant | A recommendation, then they leave | You need one question answered well |
| Agency | A team that builds a defined scope | The scope is clear and someone on your side can manage it |
The line that matters is ownership. A consultant advises. An agency delivers what was specified. A fractional CTO is accountable for whether the technology serves the business, including the parts nobody thought to specify.
When do you need one?
You likely need one if any of these is true.
- You are a non-technical founder making technical decisions you cannot fully judge.
- You rely on contractors or an agency, and nobody on your side owns the architecture.
- A product that started as a prototype now has customers, payments and data to protect.
- Investors or enterprise buyers are asking technical questions, and the answers feel improvised.
- AI is becoming central to the product, and nobody on the team has shipped it before.
You probably do not need one if you already have a strong technical co-founder, or if what you need is simply more hands on a well-run team.
What does a fractional CTO cost?
It depends on the hours and on how hands-on the role is. Engagements usually take one of three shapes, and the ranges that search summaries currently quote for the US market follow them.
| Shape | What it looks like | Quoted monthly range |
|---|---|---|
| Advisory | A standing weekly call, reviews of plans and proposals | about $3,000 to $6,000 |
| Part-time | A day or two a week, including hands-on work | about $6,000 to $12,000 |
| Embedded | Leading delivery most of the week for a period | about $12,000 to $25,000 or more |
Treat those as orientation, not a price list. What actually moves the number is scope: how many decisions are open, how much of the work the person does themselves, and how fast the company is moving. I agree the scope first and size the fee to it, so the company pays for what it needs rather than for a job title.
What are the risks, and how do you avoid them?
The model has real failure modes. None of them is a reason to avoid it, but each needs an answer before you sign.
Divided attention. Someone with several clients can be slow when you need them. Agree fixed days, a response time for urgent questions, and how the person is reached.
Strategy with no delivery. A plan nobody builds is worth very little to a young company. Choose someone who still writes code, or make sure there is a team that can act on the plan.
Knowledge that walks out of the door. If the architecture lives in one person's head, you have swapped one dependency for another. Insist that the code sits in your repository, the infrastructure runs on your accounts, and the decisions are written down.
The wrong seniority. A title is easy to claim. Ask to see products the person has shipped, and ask what went wrong on them.
How do you find and vet one?
Start with people who have hired one
Founders a stage ahead of you are the best source. Ask what the person actually did in the first month.
Look for work you can open
Live products, case studies with detail, and writing that shows how they make decisions. Anyone can describe a process. Shipped work is harder to fake.
Ask about a decision they got wrong
Senior people answer this easily and specifically. The answer tells you more than any success story.
Begin with a short paid engagement
Two to four weeks with one clear outcome, such as a written technical plan or an audit of what exists. Extend when it works.
What should the first month look like?
A good start is unglamorous. First, a plain inventory: the systems you have, the vendors, the costs, the risks, and what the business needs from technology next. Second, a short written plan that says what to build, what to buy, what to fix and in what order. Third, work begins on the part that carries the most risk, which is usually the data model, payments, permissions or the AI features.
By the end of the month you should have fewer open questions than you started with, and at least one of them should be closed by something that shipped.
What this looks like in practice
I worked with a real-estate investment team as their fractional CTO. They were running acquisitions across a marketing CRM, a separate dialer, a texting app, an e-signature service and spreadsheets holding it together. Every handoff between tools was a place for a lead to go cold.
The work was the technical direction as well as the build. The outcome was FindRE: one system for leads, calling, texting, contracts and follow-ups, with AI writing the call summaries and drafting replies. The team now runs acquisitions in it, and it is offered to other investors as a product.
That is the version of the role I believe in: decide, then build the part that matters most, and leave the company owning all of it.
For a longer view from the other side of the table, The Pragmatic Engineer's piece on becoming a fractional CTO is worth reading before you hire one. If you want to talk through your own situation, the details of how I work are on the fractional CTO page.