What does a fractional CTO actually do?

A fractional CTO is not a part-time senior employee; the role is different in kind. A startup that already has a capable team brings one in for the small set of technical decisions that are expensive to reverse and that most decide whether the product is trustworthy: the core data model, the source-of-truth architecture, the release pipeline, what the system is allowed to do when it is unsure. The job is to show up for exactly those calls, set the direction clearly, write the reasoning down so it survives your absence, and then get out of the team's way on everything else. The value is measured in expensive mistakes prevented, not in components shipped, which is why one person can hold the role across more than one company at a time.

How can one person be CTO for multiple startups at once?

By compressing each engagement to the two or three things only they can decide, and trusting the team on the rest. The hidden cost is not the work but the context switching between unrelated codebases, so you manage it deliberately: write decisions down where the team will find them, push every reversible decision back to the team, and front-load understanding a live product before touching it. The hard constraint of almost no hours per company is clarifying rather than limiting, because it forces a ruthless focus on what a product genuinely cannot afford to get wrong. There is a real ceiling on how many roles anyone can hold before switching cost eats the value.

Does a fractional CTO need to know every company's tech stack deeply?

No, and expecting to would make the role impossible across multiple companies. The stacks vary wildly (a real-time sports platform across Unity, React Native and Next.js has little in common with a clinical XR diagnostic or a React and GraphQL analytics app), but the durable skill is a way of thinking that transfers almost intact: design for being wrong by signaling uncertainty instead of faking confidence, keep one authoritative source of truth rendered in many places, and decouple what the user feels from what the system does. A new domain is then mostly learning its vocabulary. The day-one questions are always the same: what can this product not afford to get wrong, and where does the truth live.

Being Fractional CTO for Three Startups at Once: What It Actually Takes

TL;DR: For a stretch I have held the CTO title at three startups at the same time, in three different countries and three different domains: a US sports-tech platform at RAQTS, a US clinical XR product at Nystag Healthcare, and an ecommerce analytics app for Amazon sellers at Bettershop Consulting in Italy, while also engineering AI voice agents for other US teams. People assume that means doing three full-time jobs badly. It does not. Being a fractional CTO well is a specific discipline: you are hired for a handful of decisions, not for hours, and the whole skill is protecting those decisions across wildly different products without becoming the bottleneck in any of them. Here is how I actually do it.

A fractional CTO is not a part-time employee who happens to be senior. The role is different in kind. A startup that brings me in usually has a capable team already and a founder who can feel that one or two technical calls are going to decide whether the product is trustworthy, but does not have a full-time CTO's worth of those calls to make. My job is to show up for exactly those, set the direction, and get out of the way of the people writing most of the code. Do that across three companies and the constraint is brutal and clarifying: I have almost no hours in any one of them, so every hour has to land on something that only I can decide.

You are hired for judgement, not for output

The first mistake a strong engineer makes as a fractional CTO is trying to be the most productive person on the team. You cannot be, and you should not try. If I measured myself by components shipped at any of these companies I would be the worst contributor there, because I am there a fraction of the week.

What I am there for is the small set of decisions that are expensive to reverse. On the Bettershop dashboard that was the definition of profit and how returns and fees get modeled, which I wrote about in detail in building a GraphQL admin dashboard for Amazon sellers: get that data model wrong and no amount of clean React saves the product, because a seller reprices real inventory off a number that quietly double-counts a fee. At RAQTS it was the live-leaderboard architecture and the release pipeline, the two things that most decided whether players trusted the platform, which I covered in stepping in as CTO mid-build. At Nystag it was whether the eye-tracking signal was captured honestly, the whole subject of building a clinical eye-tracking diagnostic in XR.

Three companies, three domains, and in each one the job compressed to the same shape: find the two or three things the product cannot afford to get wrong, put my limited weight there, and trust the team on everything else. That compression is the only reason holding several of these at once is even possible.

The stacks are different, the discipline is not

On paper these are unrelated jobs. A real-time sports platform across Unity, React Native and Next.js has nothing in common with a clinical XR diagnostic on a Vive Focus 3, which has nothing in common with a React and GraphQL analytics app. If I had to relearn a domain from scratch each time, I could not carry three.

What makes it work is that the durable skill is not any one stack, it is a way of thinking that transfers almost intact. I have been paid for C++, Unity, AR headsets, cross-platform C# SDKs and now LLM agents, an arc I traced in my freelance lessons piece, and the constant across all of it is a small set of instincts:

Design for being wrong. A stale AR marker, a mislabeled eye-tracking sample, a profit figure with a missing fee, and a confidently hallucinated voice-agent answer are the same failure. The fix is always to build honesty about uncertainty into the surface rather than paper over it. I first learned this the hard way building AR for firefighters, where a confident wrong overlay is worse than no overlay.
One source of truth. A leaderboard position, a seller's margin, and a lead from a voice agent all have to be one authoritative object rendered in many places, never three implementations that drift. Share the truth, never the platform.
Decouple what the user feels from what the system does. True for an AR overlay, true for a data-heavy dashboard, true for the automation layer behind a voice agent.

Once you see products this way, a new domain is mostly a matter of learning its vocabulary. The questions I ask on day one are the same everywhere: what is the thing this product cannot afford to get wrong, and where does the truth live.

Context switching is the real tax, so I pay it deliberately

The honest cost of holding multiple CTO roles is not the work, it is the switching. Dropping into a codebase you were not in yesterday, reloading who decided what and why, is expensive, and if you do it carelessly you make a shallow call that the team has to unwind later.

I manage that a few ways. I write decisions down where the team will find them, not in my own head, so the reasoning survives me being away for days. I resist making reversible decisions at all and push those back to the team, spending my scarce attention only on the ones that are costly to undo. And I front-load understanding before I touch anything, because joining a live product mid-flight, which is how I came into RAQTS, means the first job is mapping what already works well enough not to break it. You earn the right to move fast by understanding the ground first, not by rewriting it.

The thing I protect hardest is not being the bottleneck. A fractional CTO who has to personally approve every merge has turned themselves into a single point of failure across several companies at once, which is the worst possible structure. The goal is the opposite: set the direction clearly enough that the team makes good calls without me in the room, and keep the number of things that genuinely need me as small as I can.

Saying no is most of the value

With almost no hours per company, triage is the job. Most weeks the highest-leverage thing I do is tell a team what not to spend time on: not to gold-plate a screen that does not decide trust, not to add a feature that muddies the data model, not to rewrite something that works. A founder can feel the pull of a dozen directions; part of what they are paying for is someone senior enough to say which two matter this month and mean it.

This is the same instinct that shows up inside the products themselves. A good voice agent is defined as much by what it refuses to do, the emergency call it escalates instead of handling, as by what it owns. A good fractional-CTO engagement is defined the same way: by the work I talk a team out of as much as the work I steer them into.

What running three at once has taught me

I do not think everyone should be a fractional CTO for three companies, and there is a real ceiling on how many of these anyone can hold before the switching cost eats the value. But the constraint has made me a sharper engineer than any single full-time role did, because it forces a ruthless honesty about where I actually add value.

You are the judgement, not the labor. If your value is measured in code shipped, you are doing the role wrong. It is measured in expensive mistakes prevented.
The transferable skill is the thing that scales, not the stack. Domains multiply; the discipline of finding what a product cannot afford to get wrong is one skill you carry everywhere.
Protect against being the bottleneck. Set direction, write it down, and make the team good without you in the room.
Triage is the deliverable. With scarce hours, choosing what not to do is often the most valuable thing you decide all week.

The through line from ICPC problem-solving to Unity to AR to AI agents to sitting in three CTO chairs is not the technology. It is learning to see, fast, what truly matters in a system and building around that first. That is the whole job, whether I am doing it for one product or three.

I lead engineering as a fractional CTO and build software and AI systems, from React and GraphQL dashboards to XR platforms and voice agents, for teams that need the hard technical calls made right. If that is you, more about my background here, or book a call.