Fractional CTO
Architecture ownership and technology judgment for companies whose decisions are getting expensive, and who are not ready to hire a full-time CTO.
Every growing company builds its technology function in the same order, and most of them skip the same step. Somebody handy keeps the lights on. An MSP takes over laptops and helpdesk. Then, when the roadmap outgrows one person, they start hiring builders. The step in between, one person accountable for how all of it fits together, never gets filled, because it is expensive and nothing is visibly on fire.
That is the role I take. The argument for why it matters is set out in full in the technology stage most growing companies skip.
Decisions, not tickets
A fractional CTO is a decision-making role. The output is not a sprint’s worth of delivery; it is the set of choices that determine what the next two years of delivery cost.
Which vendor. Which architecture. Whether to buy or build. Whether the provider’s report says what everyone thinks it says. Whether the thing being proposed survives an order of magnitude more load, or more customers, or a regulator reading it.
What makes that judgment worth anything is being able to check it. I came to this from engineering and I still do the work, so I can open the architecture, read the code, look at the cloud bill and tell you what is actually wrong. Most fractional technology leadership stops at advice, which is fine right up until the advice needs implementing.
What the role includes
Architecture ownership
One person accountable for the whole estate and how the pieces fit together. Not a diagram exercise: the running systems, the integrations between them, and the decisions that determine whether the next thing you build is cheap or expensive.
Technology roadmap
What gets built in what order, and why. A roadmap that survives contact with a board is one where each item is justified by something other than the fact that somebody asked for it, and where the sequencing reflects what makes the following item easier.
Build versus buy
Whether the thing should exist, whether the demo matches the product, and whether the problem you are buying a solution for is the problem you actually have. This is where the largest amounts of money get saved or wasted.
Cloud cost and posture
What is running, what is exposed, and what nobody can account for. Infrastructure accumulates quietly, and the cost answer and the security answer are usually the same answer: turn off what nothing is using.
Vendor and team oversight
Judging whether your providers and contractors are delivering what they were hired for, in a way that does not depend on taking their word for it. Including deciding when to stop paying for something that is not working.
Technical due diligence
On either side of a transaction. For an investor or acquirer, assessing what is actually there against what the deck claims. For a company being diligenced, finding what a buyer will find before they find it.
AI in regulated environments
Which decisions genuinely need a model and which need a well-structured query, what the data governance has to say before anything ships, and how to reach the models you need under agreements you have already signed.
Platform foundations
CI/CD, environments, observability, audit logging, and backups that have actually been restored from. The unglamorous layer that decides how fast everything after it moves.
Engineering team shape
What to hire and when, how to combine onshore and offshore, and how to keep contractors productive. Including the part where I tell you to hire somebody instead of paying me.
This is not a staff augmentation arrangement and it is not a development shop. If what you need is more hands on an agreed plan, you need engineers, and hiring them is cheaper than hiring me to write the same code. This role exists for the decisions above the plan.
Where this fits
Companies in regulated industries, where a technology decision carries a compliance consequence as well as a commercial one: medical device and SaMD companies, digital health and healthcare IT, legal, and financial services.
The common shape is a company whose product has outgrown the architecture it started on, or whose technology decisions are currently being made by whoever is nearest to them.
Where the estate itself is the problem, meaning nobody can say what is running, what it costs or what is exposed, that is scoped separately as cloud cost and posture.
The governance half of AI, meaning who is accountable, what data may go where and which vendors are approved, is AI governance and sits on the security side of the practice.
If the pressing problem is a regulator, an auditor or a security obligation rather than the architecture, that is the fractional CISO side of the practice. Plenty of companies need both, and one person holding both is usually cheaper and faster than two who have to agree with each other.
What usually brings people here
Nobody owns the whole stack
The MSP handles tickets, the developers ship features, and no single person can tell you how it all fits together, what it will cost to change, or where it is exposed.
A project is over budget, past its date, and still not working
You need somebody who can tell you what is actually wrong rather than what is politically convenient, and then go and fix it.
You are about to hire engineers and are not sure which ones
Hiring is the most expensive way to discover you diagnosed the problem wrong. More builders rarely fixes a problem caused by the absence of an architect.
The cloud bill is growing faster than the business
Nobody can say what half of it is for, and the people who provisioned it have moved on. The answer is usually not a discount negotiation.
A transaction is coming and the technology has to stand up to it
Diligence asks questions that the inside of a company rarely asks itself, and the answers are much cheaper to find before somebody else does.
The board wants a technology strategy it can trust
Somebody has to own the estate and defend the plan to the people writing the check, in terms they can act on.
How engagements are structured
Fractional technology leadership is a retainer. That is different from fixed-bid project work, and the difference is deliberate: a project has a finish line, and holding a role does not.
The retainer is sized by the responsibilities I own, not by the hours I am in the building. The value is concentrated in a handful of moments rather than spread evenly across the month. You still decide. You decide from a position of knowledge rather than ignorance, and over three years that difference compounds into either a platform or a rewrite.
Every engagement starts by writing down which responsibilities are mine, what arrives on what cadence, and what I am accountable for producing. The role reports to the CEO or the board. A monthly fee for unspecified availability is how these engagements quietly turn into nothing.
Retainers start at $5,000/month. Where an engagement lands above that depends on the size of the estate and how much of it is urgent. Defined problems with a clear finish line, including due diligence and architecture review, are quoted fixed-bid instead.
The two engagement models, and what each phase produces, are set out on how I work.
Everything I build, document and configure is yours, and the engagement is designed so you can end it without losing anything.
Versus the alternatives
Versus more developers
The most common substitution, and the most expensive. One company put real time and real money into an AI-powered search product that could not find what its users needed, because whoever chose it had no application background and there was nobody in the building whose field it was. The problem was never the search engine. It was tens of thousands of records whose meaningful content sat unstructured in free-text fields. Once that was named correctly the fix was quick.
Engineers execute decisions. They do not decide whether the thing being built should exist, whether the architecture survives the next order of magnitude, or whether the vendor’s demo matches the vendor’s product. Those decisions have a far larger blast radius than any individual sprint, and they are the ones companies currently make without help.
Versus a full-time hire
The rule I use: hire full-time when there is enough work in one specialization to keep one person genuinely busy.
A regulated connected product needs a mobile engineer, a cloud and infrastructure person, a security specialist, and a portal developer across front and back end. Those are four different jobs, and early on none of them is a full-time load. Hiring four people to cover four part-time loads is how a company burns its runway.
What the role does is direct all four: set the architecture they work within, judge whether the work coming back is right, and step in directly where the gap is doing real damage. It also answers the question you actually need answered, which is which of the four to hire first.
The moment any one of them becomes a full week of work, hire for it. I will say so, and I would rather say it early than bill through it.
Versus an MSP
An MSP delivers services against a defined scope. It does not decide what your architecture should be, and it has no commercial reason to tell you that the thing it is running for you should be switched off.
Why me
I co-founded a SaaS conferencing platform, built PCI DSS-compliant billing from nothing, grew it to 10,000 customers and $9M in revenue, and sold it to NTT. I stayed six years, ascending to CTIO with 225 reports across eight countries and a $33M budget, reporting in turn to the board, the parent company board, and executive leadership.
After that I joined a healthcare workforce startup as employee number five, rebuilt the engineering organization to 40-plus, and helped lead the company to acquisition. Two exits.
Since then: a legacy Java EMR migrated to Azure, a digital banking platform migrated for 130,000 members, a cybersecurity program carried through an FDA submission, and a penetration test taken from report to a clean retest. The full set is in the case studies.
If that background is not the shape of your problem, I will tell you in the first conversation rather than the third invoice.
Questions I get asked first
What does a fractional CTO actually do?
Owns the architecture and the technology roadmap. Which systems exist, how they fit together, what gets built versus bought, what the cloud estate costs and exposes, and whether the next thing you build makes the one after it cheaper or more expensive. It is a decision-making role, not a delivery role, and the value sits in a handful of moments each month rather than spread evenly across them.
How is this different from hiring more developers?
Engineers execute decisions. They do not decide whether the thing being built should exist, whether the architecture survives the next order of magnitude, or whether a vendor demo matches the vendor product. Those decisions have a far larger blast radius than any sprint, and more builders rarely fixes a problem caused by the absence of an architect.
What does it cost?
Retainers start at $5,000 a month, scoped against the size of the estate and what is actually urgent. Fixed-bid project work is the other option where the problem has a defined finish line. I do not sell hours.
Do you write code, or just advise?
I can read and write code, and that is what makes the architecture judgment checkable rather than theoretical: I can open the system, look at the cloud bill, and tell you what is actually wrong rather than what is politically convenient. But this is a leadership role, not a development engagement. If what you need is more hands on an agreed plan, hire engineers. That is cheaper than hiring me to write the same code.
Can you do technical due diligence for an acquisition?
Yes, on either side. For an investor or acquirer that means assessing what is actually there against what the deck claims. For a company being diligenced it means finding what a buyer will find, before they find it.
What about AI in a regulated environment?
The common failure is not the stalled pilot everyone expects. It is adoption that succeeded with no governance around it at all: staff using assistants daily, no acceptable use policy, and nobody able to say what happens to the data. That gap is cheap to close and it is usually the first thing worth fixing.
Written on this
Start with a conversation
Tell me what’s going on. If a fractional arrangement is the right answer I will scope it. If it is not, I will say what is.
Bring your architecture problem, stalled project, cloud bill, or diligence deadline.
Not ready for a call? Send a message instead.
For companies looking to engage BATO. Vendors, please email.