Senior technical leadership for a company that needs the decisions, not the headcount.
The architecture, hiring and build-or-buy calls that decide what the next two years cost, made by someone who has made them before and will not be here forever.
Building and running software since 2007The exit written down at the start, not negotiated at the end
- Build or buy the billing engine11 weeks
- Second engineer, or a contractor7 weeks
- Data residency for the EU customer5 weeks
- Replace the queue, or live with it3 weeks
- Move staging off the founder laptopDecided
Illustrative of the shape of the queue, not a client record.
Four situations that produce the same call.
This is the wrong hire when the real gap is delivery capacity, or when a trusted technical leader is already in place. A second voice there produces argument, not direction.
Decisions are stacking up behind one founder
Every technical question routes to the person who also has to sell, hire and raise. The queue itself is now the constraint.
The team can build but nobody owns the shape
Good engineers, no one accountable for whether the parts fit, so the system grows by accretion and each change costs more than the last.
Someone external has started asking hard questions
An investor, an acquirer or an enterprise customer wants answers about architecture, security and risk that nobody internally is positioned to give.
A leadership gap opened and the roadmap did not stop
The previous lead left. Hiring a replacement takes as long as it takes, and decisions cannot wait for it.
What the engagement covers.
Six areas, ordered by how long each decision's tail is. The first two are the ones that decide what the next two years cost.
Architecture and the build-or-buy calls
What gets built, what gets bought, and what gets deliberately deferred. These are the decisions with the longest tail.
Technical roadmap tied to the commercial one
Sequencing work against what the business has committed to, rather than against what is most interesting to build.
Engineering hiring and team shape
What roles to open and in what order, plus sitting on the technical side of interviews so the bar is consistent.
Security and risk posture
Getting the answers straight before an enterprise customer or an investor asks for them, which is a different exercise from being asked.
Vendor and platform decisions
Choosing what you depend on, and knowing what each dependency costs to leave.
Delivery practice that holds without us
Review, release and escalation habits that survive a change of personnel, because that is the point.
Where testing is the gap, that is QA and software testing. Where the work uncovers something to build, that is custom software development, scoped on its own terms.
See QA and software testingA fractional CTO is one of five answers. Here is how to tell which one you need.
Most pages on this term assume the answer is a fractional CTO. Usually it is not. What matters is the actual gap: judgement, capacity, structure, or credibility.
5 situations1 of them leads to a fractional CTO
Nobody senior is deciding, and decisions are compounding
Fractional CTOThis is the case the role exists for.
Decisions are made, the work is not getting done
A senior engineer, or more of themLeadership does not add throughput. You will pay for judgement you already have.
The system design is wrong, but direction is clear
A solutions architect, engaged narrowlyA scoped design problem, not an ongoing leadership one. Faster to solve directly, and it ends.
An investor or acquirer wants technical assurance
A technical review, then decideFind out what the answers are before hiring someone to give them. The review often shows the role is not needed.
The product direction itself is unsettled
Nothing yetA technical leader hired into an unresolved product argument will spend the engagement inside that argument.
We say this before an engagement rather than after one, because two of these five rows point away from work we would be paid for.
How it runs in practice.
Commitments first, then the system as it actually is, then the decisions that are genuinely blocking. The exit is designed in step five, not discovered later.
Understand what the business has promised
Customers, investors, a board. Technical decisions are only right or wrong relative to commitments already made, so that comes first.
Read the system as it is, not as documented
The code, the pipeline, the incidents and where people work around things. The workarounds are usually the most honest source in the building.
Name the decisions that are actually blocking
Written down, ordered by what they cost to leave open. Most companies have fewer of these than they think, and they are not the ones being discussed.
Work inside your team's rhythm
Your reviews, your planning, your escalation path. A leader operating outside the team's cadence produces documents rather than decisions.
Build the exit from the start
The engagement is meant to end. What has to be true for that to happen is written down at the beginning, not negotiated at the end.
Inside your rhythm. A leader operating outside the team's cadence produces documents rather than decisions.
Closest available, not equivalent.
We have no published fractional CTO engagement. What follows is evidence that we have made these decisions inside our own work, not a leadership contract.
Nineteen years of build-or-buy calls
Software delivered across six countries since 2007.
The value of the role is having been wrong before in ways you can name, and that is what this length of record buys.
Vizitor, a platform that had to keep working
Contextual scale: 500+ workplaces across 15+ countries.
Software at that spread is a series of architecture decisions that either held or did not.
Fitelo, an AI product with controls in place
Evaluation and cost controls set up in production rather than added after an incident.
Which is a technical leadership decision before it is an engineering one.
Deliberately absent
Every competing page in this search result carries at least one of these. None of ours is sourced, so none of them appears.
- No named fractional CTO client
- No founder quote
- No retained-client count
- No equity or ownership arrangement
- No engagement length
The situations we have led through.
Framed as situations rather than industries, because the decisions that stack up look much the same whatever the company sells.
Founder-led companies past first product
Where the thing works, growth has started, and nobody has yet owned what it should become.
Teams inheriting a system somebody else built
Where the constraint is understanding what exists before deciding anything about it.
Companies selling to larger customers
Where the technical questions in a procurement process arrive faster than the answers.
Products adding AI to something that already worked
Where the risk is not the model, it is what the model is allowed to touch.
What has to exist before the engagement can end well.
Fractional leadership has a failure mode nobody selling it describes: the role becomes permanent because nothing was written down, so the decisions only ever lived in one head.
The decisions recorded with their reasons
Not what was chosen. Why, and what the alternative was. A record without reasoning cannot be revisited when conditions change.
A named internal owner for each area
Someone inside who can carry each decision forward. If every area still routes to us, the engagement has not worked.
The technical answers a third party will ask for
Written down and current, so a procurement or diligence question is retrieved rather than reconstructed.
A roadmap your team can defend without us
The real test. If they can explain the sequencing to a board, the judgement has transferred.
Every benchmark page treats continuation as the good outcome. We treat it as the thing to design against.
We would rather write this down at the start and be measured against it than sell an engagement that quietly becomes a fixture.
What working with us actually looks like from the inside.
Four things that are true of the arrangement rather than of the deliverables, because those are what a reader is actually weighing.
We work through your people, not around them
Decisions are made with the engineers who will live with them. A call handed down without the team in the room gets re-litigated the first time it is inconvenient.
Nothing is held hostage
Documents, decisions and access sit in your systems. If the arrangement ends, nothing has to be extracted from us first.
We will tell you when the answer is not us
Including when the work should go to an internal hire, to a narrower engagement, or nowhere yet. Two rows of the table above already say this.
Delivery capacity is separate, and stays separate
If the engagement uncovers work that needs building, that is a different conversation and a different scope.
Tell us which decision is stuck.
We will tell you whether this needs a fractional CTO, narrower work, or nothing yet. Two of the five situations above are not engagements we would take.
The four questions we are actually asked.
Pick a topic, or ask us directly. We answer every inbound within one business day.
Still have questions?
Talk to a senior engineer, not a bot.