"Fractional CTO" has become the title people put on their LinkedIn profile when "senior developer" doesn't sound senior enough.

I play this role for some of my clients, so I have opinions about what it actually means — and what it doesn't. The confusion isn't just semantics. If you hire the wrong thing under this label, you pay consulting rates for work that a good contractor would have done better.

The Problem with the Label

The term covers a surprisingly wide range of people and arrangements. At one end, you have experienced technical leaders — people who have actually run engineering organizations, made architectural decisions that constrained companies for years, hired and let go technical staff, and owned the consequences. At the other end, you have developers who decided their day rate felt more justifiable with a fancier title.

Both call themselves fractional CTOs. The market hasn't sorted this out yet.

The reason it matters: these are fundamentally different services with different prices, different deliverables, and different risks. Mixing them up is how companies end up paying €200/hour for someone to help them choose a JavaScript framework.

What a Real Fractional CTO Actually Owns

Owns is the operative word. Not "advises on." Not "contributes to." Owns.

Technical architecture decisions. When you're building a system that will handle real volume, real users, and real money — the decisions made in the first few months constrain everything that follows. What database, what caching strategy, how the services are separated, where the complexity lives. A fractional CTO makes those calls and stakes their reputation on them. They're not writing a report about options. They're deciding.

Tech stack and vendor selection. When a vendor pitches you something, someone needs to evaluate it who has seen enough vendors to know which ones are overselling. When a developer suggests a library, someone needs to know whether it's the right tool or just the tool that developer happens to know. That judgment is not something you can crowdsource to your team if your team is junior or you don't have one yet.

Technical hiring. Writing job descriptions, running technical interviews, deciding what "senior" actually means for your context. This is one of the highest-leverage things a fractional CTO does, because bad technical hires compound. One wrong hire sets the engineering culture back a year.

Security posture. Not penetration testing or compliance audits — those are specialist work. I mean the baseline: who has access to what, what happens when someone leaves, whether your production credentials are in a git repository somewhere, whether there's a recovery procedure for when things go wrong. Most companies in the 30-150 employee range have never had anyone systematically look at this. The first-week IT audit I do with new clients is usually where this picture comes into focus.

slug="fractional-cto"
text="Need senior technical ownership without a full-time hire? I act as fractional CTO for early-stage and scale-up teams — making architecture decisions, running technical hiring, and owning the outcome."
/>

Team structure as you scale. When to hire in-house versus keep using contractors. When a team of two becomes a team of six and needs coordination. Where the bottlenecks are and how to address them without adding headcount that isn't needed yet.

What a Fractional CTO Does Not Own

This part is where the confusion usually happens.

The product roadmap. A fractional CTO advises on technical feasibility, complexity, and risk. They don't own the product decisions. When the product manager wants to build feature X and the fractional CTO thinks feature Y is more important, the fractional CTO makes the technical case and then accepts the product decision. Owning the product is the founder's job, or the CPO's job. Not mine.

Business strategy. I can tell you what's technically possible and what it costs to build. I can tell you when a technical decision has business implications you may not have thought about. But I can't tell you which market to enter, which customer segment to prioritize, or what your pricing model should be. That's not my domain.

Project management. Tracking who is doing what, when things are due, what's blocked and why — that's a project manager or an engineering manager, depending on the size of the team. A fractional CTO who is spending significant time on project management is filling a gap that shouldn't exist. Either the team needs a PM, or the team needs to get better at self-organization.

Customer relationships. I talk to clients when there's a technical question that needs a senior answer. I don't run client calls. I don't manage expectations about delivery timelines. The account relationship lives with whoever owns accounts.

The short version: I own the technology. I influence the business. I don't run the business.

When You Actually Need One

The honest answer is: later than most people think, and differently than most people expect.

Early-stage startups, pre-product-market-fit, usually don't need a fractional CTO. They need a good senior developer who can make reasonable technical decisions while building fast. If you have one strong technical founder, they're probably fine handling architecture decisions themselves with occasional external input.

The need becomes real when one of these is true:

• You have a team of developers and nobody is accountable for technical direction — independent decisions that don't add up to a coherent system, and debt accumulating faster than it's being addressed.
• You're about to make a major technical decision — new platform, new infrastructure, significant architectural change — and you don't have anyone senior enough to own that decision confidently.

Or: you're a non-technical founder who is about to hire your first engineers and you need someone to run the process and set standards before bad patterns get embedded.

Or: something has gone wrong — the system is unreliable, a previous developer left a mess, you need to understand what you have before deciding what to do next. This is closer to a rescue engagement than ongoing fractional CTO work, but the skills overlap.

What you probably don't need a fractional CTO for: adding features to a stable system, maintaining existing integrations, shipping a landing page, routine development work. A contractor handles that better and for less.

What an Engagement Actually Looks Like

This varies significantly, but the pattern I've seen work is roughly:

The first few weeks are diagnostic. I'm reading code, talking to developers, understanding the current state, identifying the biggest risks and the most important decisions that haven't been made yet. This is not the time for major changes — it's the time to understand what's there before touching it.

After that, the work settles into a rhythm. Some combination of availability for decisions and questions, regular reviews of technical direction, involvement in hiring when it comes up, and specific project work when there's something architectural to build or fix. The time commitment is usually 10-20 hours per week — enough to be genuinely embedded, not so much that it's a full-time role.

The engagement should have a natural endpoint or at least a transition point. Either you hire a full-time CTO as you scale, or the technical situation stabilizes enough that ongoing fractional involvement isn't needed. An engagement that stretches indefinitely without a clear reason is usually a sign that something wasn't defined well at the start.

The model has real limitations worth naming. Someone embedded 10-15 hours a week carries less context than a full-time technical leader. There will be decisions made while you're not in the room, and things that break at 11pm depend on how well the team has been set up to handle them independently. This is the tradeoff: senior judgment at a fraction of the cost, but not a substitute for eventually hiring that person full-time if the business grows to need one.

How to Tell the Difference

The question I'd ask anyone selling fractional CTO services: what technical decisions have you made that turned out to be wrong, and what happened next?

Everyone makes bad technical calls. The developers who've never made one haven't worked on anything complex enough to matter, or they're not being honest. What distinguishes a real technical leader is how they handle it when they're wrong — whether they recognize it early, communicate it clearly, and fix it decisively.

Someone who tells you they've never made a significant mistake is either lying or has never been accountable for significant decisions. Both are disqualifying.

The other signal is specificity. When I describe technical architecture work, I can tell you exactly why I chose Redis over Memcached for rate limiting in vatnode.dev, what the tradeoffs were, and what I'd do differently with hindsight. I can tell you why the order automation in pikkuna.fi uses BullMQ for the processing queue and what failure modes we designed around. Real work leaves specific marks. Vague consulting language is a red flag. If you want to evaluate a candidate's past decisions, a technical due diligence lens — applied to their previous projects — is the most reliable signal.

The Overlap with Technical Co-Founder

For very early-stage startups, the fractional CTO conversation often runs into the technical co-founder conversation, and they're worth distinguishing.

A technical co-founder has equity, long-term alignment with the business, and typically is building the product themselves. A fractional CTO has a fee, a defined scope, and is usually not building things hands-on — or only doing so as a temporary bridge.

The fractional model works well when you need senior technical judgment for a defined period, don't have the runway to attract a full-time technical co-founder, or aren't ready to give equity to someone who hasn't proven themselves in your specific context yet. It's a real solution, not a consolation prize — but it's different, and the expectations need to be set accordingly. For a broader view of where this role fits in the landscape of IT ownership, what happens when nobody owns your IT is the clearest adjacent read — and developer vs IT partner covers the distinction that trips up most hiring decisions.

items={[
{
q: "What does a fractional CTO actually do?",
a: "A fractional CTO owns technical architecture decisions, leads tech stack and vendor selection, runs technical hiring, establishes security posture, and sets team structure as you scale. The operative word is owns — not advises on, not contributes to. They stake their reputation on the decisions and are accountable for the outcome.",
},
{
q: "How is a fractional CTO different from a senior contractor?",
a: "A senior contractor executes defined work — building features, maintaining integrations, shipping a landing page. A fractional CTO makes architectural decisions, defines what should be built and how, and is accountable for technical direction. You hire a contractor when the work is defined. You hire a fractional CTO when nobody is qualified to define the work.",
},
{
q: "When does a startup actually need a fractional CTO?",
a: "Later than most founders think. Early-stage pre-product-market-fit teams usually need a strong senior developer, not a fractional CTO. The need becomes real when: you have a team with no one accountable for technical direction, you are about to make a major architectural decision nobody can own confidently, or you are a non-technical founder about to hire your first engineers.",
},
{
q: "How much does a fractional CTO cost?",
a: "Rates vary widely — roughly €100-250/hour depending on experience and scope. Most engagements run 10-20 hours per week, which puts monthly cost at €4,000-20,000 depending on rate and hours. This is a fraction of a full-time CTO salary (typically €150,000-250,000/year in the EU), which is the point of the model.",
},
{
q: "How do I tell if a fractional CTO candidate is the real thing?",
a: "Ask them: what technical decisions have you made that turned out to be wrong, and what happened next? Real technical leaders have made significant mistakes and can describe them specifically. Vague consulting language and an absence of concrete failure stories are red flags. Specificity is the signal — they should be able to tell you exactly why they chose Redis over Memcached in a real project and what the tradeoffs were.",
},
]}
/>

---

Done well, a fractional CTO engagement should make itself unnecessary. The goal is a technical organization that has good instincts, clear standards, and the people to execute — not indefinite dependence on outside judgment.

If you're trying to figure out whether your situation calls for a fractional CTO, a senior contractor, or something else entirely, let's talk. I can usually tell you which one you actually need in a single conversation — and if it's not me, I'll say so.