Technical leadership without hiring a full-time CTO
Plenty of companies make structural technical decisions with nobody whose job it is. The founder decides alone, or asks the supplier who has an interest in the answer. A fractional CTO fills that gap a few days a month.
The problem it solves
An architecture decision, a supplier choice or a code takeover is decided once and paid for over five years. Most companies between twenty and two hundred people have nobody to arbitrate those: the founder decides on instinct, or asks the supplier who is about to sell the work.
Hiring a CTO solves it and costs an executive salary plus three to six months of recruitment. For many, the real need is two to four days a month of senior judgement, not a full-time role.
What the role actually does
Arbitrates the decisions that are expensive to undo: stack choice, system boundaries, buy against build, migration sequencing. Reads a supplier's proposal with the eye of someone who has nothing to sell on that particular lot. Puts in place what is almost always missing: environments, CI, code review, access management.
It also makes the technical side legible. A non-technical founder should be able to say where the engineering budget goes and what lands next quarter, without translating jargon they were handed.
What it is not
Not a developer. If you need someone writing the code, that is staff augmentation and it is priced differently. Not a project manager either: the role decides technical direction, it does not run a schedule day to day.
And not a disguised route to selling you a team. A fractional CTO who always recommends their own employer is worth nothing to you. If the right call is to keep your current supplier, or to bring the work in house, that is what you will hear.
Technical due diligence
The second use of the role is one-off: assessing a codebase before an acquisition, a raise or a takeover. What the code actually does against what the documentation claims, the real debt, the abandoned dependencies, and what happens if the person who wrote it leaves.
The deliverable is a written opinion separating what is sound, what is repairable and what will have to be rewritten, costed in effort rather than in adjectives.
The role is sized in days per month, not in full-time equivalents. Below a certain threshold there is not enough continuity to be useful.
- Recurring arbitration2 to 4 days a monthArchitecture decisions, proposal review, a monthly session with leadership.
- Setting the basics upShort engagement, then recurringEnvironments, CI, code review and access management where none exist.
- Technical due diligenceOne-off, 1 to 3 weeksWritten opinion on a codebase before an acquisition, raise or takeover.
- Mentoring an internal team2 to 6 days a monthFor a junior team with no senior to review them or grow them.
Common questions
- At what size does this make sense?
- In practice, as soon as there is software in production that the business depends on and nobody internally whose job it is to arbitrate it. That often happens well before twenty people.
- What if your advice is not to work with you?
- Then that is what you get. An arbitration role that always recommends its own employer has no value, and it shows within two meetings.
- Does the role recruit for us?
- It can scope the need, write the brief and run the technical part of interviews. The recruitment itself stays with you or with an agency.
- How long is a typical engagement?
- Long enough for continuity to be worth something, so several months, with a short notice period. Due diligence is the exception: one to three weeks, with a deliverable and an end.
Describe the decision that is stuck
Tell the scoping assistant what needs arbitrating and by when. It asks the questions a senior engineer would, then returns an estimate with a format and a start date.
Scope an engagement- Technical debt: what it costs and when to repay itHalf of what gets called technical debt is not debt. How to tell deliberate borrowing from ordinary mess, how to make the cost legible to a board, and why some of it should be left exactly where it is.
- What is IT outsourcing? Models, risks, and how to chooseThe word covers five arrangements that have almost nothing in common, and most bad outsourcing deals start with two parties using it for two different things. What each model means, who carries the risk, and when not to outsource at all.
- Software development quotes: how to compare themTwo quotes for the same brief can differ by 3x without anyone lying. Here is how to bring them down to days, rates and scope before you sign.
- Fixed price vs time and materials (and the pod)The contract model decides who pays when the scope turns out to be wrong. We compare fixed price, time and materials and the pod using our own terms: public rates from 150 to 450 EUR per day, pods from 15 to 40K per month.
- IT staff augmentationNamed engineers inside your existing team, on a European working day, contracted through Belgium.
- Nearshore vs offshoreA straight comparison for European teams who already offshore and are weighing a move closer.
- Nearshore development teamA dedicated group that owns delivery end to end, from architecture through production support.
- Managed IT and cloudCloud, pipelines, domains, mail and access, held by the team that also knows the code.
- Cloud migrationInventory, batched cutovers and a tested rollback, so the move does not depend on luck.
- Infrastructure as codeEnvironments described in code, reviewed and rebuildable, instead of configured by hand once and never again.
- AI and chatbot engineeringModels integrated into software that has to run, with a straight answer on what will not work.
- Shopify developmentFor Shopify stores that have to talk to an ERP, a stock system or a payment flow.
- Data engineeringWarehouse, pipelines and reconciliation, so the numbers can be trusted.
