That detail sits in the New York Times profile of 2 April 2026, which verified that his telehealth company, Medvi, did $401 million in sales in 2025 and $65 million in net profit. He started it from his house in Los Angeles in September 2024 with $20,000. His only employee is his brother.

Six weeks before that profile ran, on 20 February 2026, the FDA issued warning letter 721455. It was addressed to Medvi LLC.

The lasagna test checks whether the bot stays on topic. The other test is the one nobody runs: when something goes wrong, whose name is on the envelope.

The thesis

The one-person company did not remove the org chart. It rented it. AI made renting cheap enough that a founder can run a nine figure business through partners, contractors and agents, so headcount now measures payroll, not the organisation. Every consequence of the work still comes home to the brand. Headcount has become the least informative number in a small company, and the number that replaced it is one almost nobody writes down: the functions you answer for that somebody else performs.

What actually changed

Here is the Medvi org chart as the Times describes it. CareValidate and OpenLoop Health supply the doctors, the pharmacies, shipping, compliance and the customer service calls. Two engineers are on contract. A law firm replaced LegalZoom. An accounting firm replaced the AI accounting tools. Media agencies buy the ads. ChatGPT, Claude and Grok built the website, Midjourney and Runway make the images, ElevenLabs does the voice. The brother, hired in April, filters communications. Gallagher himself told the Times it is not technically a one-person company.

That is not a small organisation. It is a large one with a short payroll.

What AI changed is the coordination cost. Renting six functions used to mean six account managers, six contracts and a full time operations hire to hold them together. Gallagher built custom agents so his software systems talk to each other. The glue that used to need people became code, so a founder can rent almost everything and still run the machine from a laptop.

What AI did not change is where the consequences land. The FDA letter cited the website for presenting compounded drugs under the Medvi name, which implied Medvi compounds them, and for the line “Same active ingredient as Wegovy and Ozempic”. A partner pharmacy does the compounding. The letter still went to the brand. Regulators, customers and courts do not read your vendor list. They read your logo.

I have written code for 30 years and I now build software for private equity. When a small company tells me its headcount, I ask for a second list before I read anything else: every function a regulator, a customer or a court would hold the company responsible for, and the name of the person or firm that actually performs it. The gap between those two lists is the real size of the company.

Three cases

The supplier you share with your rivals. On 12 March 2026 STAT reviewed more than 70 telehealth companies the FDA had warned in the previous six months. At least 30% publicly listed affiliations with the same four nationwide medical groups: Beluga Health, OpenLoop, MD Integrations and Telegra. The rented org chart is not exclusive. It is the same org chart rented to your competitors, so its failures arrive for all of you at once.

The breach that was not yours. OpenLoop’s systems were breached on 7 and 8 January 2026. The federal breach portal now lists up to 716,000 individuals, and the Texas Attorney General separately lists 68,160 Texas residents. OpenLoop sells platform services to many healthcare brands, so the people affected sit across many client organisations. I am not claiming any particular brand’s patients were among them. The point is structural. If you rent the platform, the incident belongs to somebody else and the patient’s anger belongs to you.

The price of the people. Wix bought Base44 in June 2025 for $80 million in cash. It was six months old, bootstrapped, and celebrated as a solo founder’s company. It had eight employees, and $25 million of the $80 million was set aside as retention for them. Thirty one percent of the price of the most famous one-person exit was paid to keep the people. The acquirer did the arithmetic the headcount story skips.

Carta’s data says the pattern is spreading and that capital has noticed. Solo founders started 23.7% of new US startups in 2019 and 36.3% in the first half of 2025. In 2024 solo-led companies took 14.7% of the cash raised in priced equity rounds. More than a third of the companies. Under a sixth of the money.

Where this breaks

Renting is usually the right call. OpenLoop can carry more clinical compliance capacity than any founder could hire in year one, and Medvi’s 16.2% net margin against 5.5% at Hims & Hers says the rented model can beat the owned one on the P&L. I agree with all of that. The argument is not that you should hire. It is that you should stop reading a short payroll as a short list of exposures.

It also matters less where the liability surface is small. A developer tool sold to developers can rent nearly everything with little regulatory exposure. Healthcare, finance, food, anything with a licence or a patient: that is where the rented org chart bites.

Dario Amodei, asked in May 2025 when the first billion dollar company with one human employee would appear, answered “2026.” On revenue he may well be right. My objection is to the word employee. It was always a payroll term, and payroll was never where the risk lived.

What I would do on Monday

1. Write two columns: every function the business answers for, and who performs it. Mark each rented line.

2. For every rented line, find out which of your competitors rent the same supplier. A shared supplier is a shared failure point.

3. Put one named internal owner on every rented function, even if that owner is you, with hours budgeted each week to read what the partner is doing in your name.

4. Rewrite partner contracts so any incident and any regulator contact reach you within 24 hours, with the right to review every claim made under your brand before it runs.

5. If you are buying or funding one of these companies, price it the way Wix did. Ask what share of the price depends on people staying, and whose payroll those people are on.

The other test

Gallagher’s lasagna test was a good one. It caught a bot drifting off its job, and he fixed it.

Run the second test before you need it. Pick any line on your rented list, assume it fails tonight, and ask who gets the letter.

At Medvi, the letter came to Medvi.

Most of what I write about here started as a client problem. If you are deciding what to rent and what to own, grab thirty minutes with me.

He was not talking about the code. The code survives. It sits in the repository, it compiles, it passes its tests. What dies is anyone’s ability to say why it is the way it is, and therefore what is safe to change.

Forty one years later, the code is the cheap part. The theory is not.

The thesis

When AI collapsed the cost of writing code, the handover became the only deliverable in an engagement that got more expensive. What a client is actually buying now is the reason each decision was made. Almost nobody prices that separately from the code, and on any system with money running through it, it should be the larger line.

What changed

Three numbers tell the story of the build. Google said about 25% of its new code was AI generated in October 2024. By late 2025 it was reported at 50%. In April 2026 TechSpot reported Google putting the figure at roughly 75%, with engineers reviewing the output. Whatever your own number is, the direction is the same. The marginal cost of producing code is heading towards the cost of reviewing it.

That changes what a handover document is worth, because a handover has two halves and AI only touched one of them.

The first half is what the system does. Which services exist, what calls what, where the data lands. That half is now derivable. Point a model at the repository and you get an accurate tour in minutes. So a handover that describes the system is worth roughly what it costs to regenerate, which is close to nothing.

There is evidence for this. A team at ETH Zurich evaluated repository context files, the AGENTS.md and CLAUDE.md files developers now write for coding agents, in a paper accepted at ICLR 2026. Their finding: context files, whether model generated or committed by developers, generally did not improve task success, and they raised inference cost by over 20% on average. Repository overviews in particular did not help. I read that as a clean result. A description of the repository is redundant with the repository.

The second half is why. Why this queue and not a cron job. Why the pricing table is duplicated in two places. Which alternative was tried in March and abandoned, and what broke. Which constraint came from the client’s finance team and not from engineering at all. None of that is in the code, and no model can infer a conversation that was never written down.

Naur put it precisely. The programmer who holds the theory “can explain why each part of the program is what it is” and “is able to respond constructively to any demand for a modification of the program”. That is the asset. It is also the only asset in the engagement whose replacement cost went up this year.

It went up because volume went up faster than understanding. GitClear analysed 211 million changed lines and found moved lines, its proxy for refactoring, fell 39.9% in 2024. Blocks of five or more duplicated lines rose eightfold, and copy pasted lines outnumbered moved lines for the first time. More code per person who understands it means the theory is spread thinner every quarter.

I have written code for 30 years. In every system I have been handed in that time, the code told me what. The expensive week was always the one spent finding the person who could tell me why, and the worst weeks were when that person had already gone.

Three cases, all public

Naur’s own compiler. The 1985 paper rests on a real case. A second group took over a working compiler to extend it, with “full documentation, including annotated program texts and much additional written design discussion”, plus advice from the team that built it. In several major cases their extensions were patches that ignored facilities the compiler already had, facilities the documentation discussed at length. The original team spotted it immediately. Ten years later, under other maintainers, the original structure was “still visible, but made entirely ineffective by amorphous additions.” That was a well documented system. The documentation described it. It did not explain it.

The truck factor. In a study of 133 popular GitHub applications, Avelino and colleagues found 46% had a truck factor of one and a further 28% had a truck factor of two. Nearly three quarters of widely used open source applications would lose most of their theory with two departures. Those are public projects with public commit history and public issue threads, which is the best case. A private codebase built by a contractor on a fixed term is worse.

The rent on a missing why. The 2024 Stack Overflow survey found over 60% of developers spend at least 30 minutes a day looking for answers, about one in four spend an hour or more, and 30% say knowledge silos hit their productivity 10 or more times a week. That is the cost of an unwritten theory inside companies where the people who hold it are still employed. After the handover, the people are gone and the rent becomes a rewrite.

The fix has existed for fifteen years. Michael Nygard proposed the architecture decision record on 15 November 2011, five headings: title, context, decision, status, consequences. His reason was exact. Someone new to a project, without the rationale, has two choices: “Blindly accept the decision” or “Blindly change it.” AI made the second option fast and cheap. That is the problem, not the solution.

Where this breaks

The strongest objection is that models will recover the why from the exhaust: commit messages, tickets, pull request threads, chat history. Partly true. Where a decision was argued in writing, retrieval finds it, and that is a real gain. But the expensive decisions are usually the ones made in a meeting, and a rejected alternative leaves no trace in the code that replaced it. Retrieval recovers what was written. It cannot recover what was not.

Second, Naur himself argued the theory cannot be fully written down. Granted. A decision record is a lossy copy of what the team knew. It does not replace the team. It shortens the revival, and on a system with live revenue paths, the length of the revival is the cost.

Third, a growing share of code is disposable. Prototypes, internal tools, a script due to be replaced next quarter. If rewriting is close to free, rewrite it and skip the record. That is a fair call, and I make it myself. The thesis bites on the other kind of system: the one with customers, integrations and money flowing through it, where a blind rewrite is the most expensive option on the table.

What I would do on Monday

1. Split the next statement of work into two priced lines: the build, and the decision record. If the second line is zero, you are buying code you will not be able to change.

2. Require one decision record per non obvious choice, on Nygard’s five headings plus one more: what we chose not to do, and why.

3. Test the handover before the team leaves. Give an engineer who has never seen the system the records and one real change request. Time how long it takes them to say whether the change is safe.

4. Stop paying anyone to write repository overviews. A model produces those on demand, and the ETH Zurich result says they do not help much anyway.

5. For every path that touches revenue, count the people who can explain why it works the way it does. Where the answer is one, you have found your exposure.

The close

Naur wrote one more sentence in that paper. “Revival of a program is the rebuilding of its theory by a new programmer team.”

The code will still compile the morning after the team leaves. It always has. The question was never whether the program runs. It is whether anyone left can tell you why.

Most of what I write about here started as a client problem. If yours is a system nobody left in the building can explain, put it on my calendar.

Last month I wrote an AGENTS.md. No human has read it. It is loaded in full at the start of every agent session, and every one of those loads is billed to me.

Thirty years of writing software and I have never had a document charge rent before.

The file is a purchase

The agent context file is not documentation. It is a line item with a per use price, the price is measurable, and almost nobody has measured it. The evidence we have says you are paying a certain cost for an uncertain gain, and you are paying it on every run for the life of the repository.

That is a procurement decision. It is currently being made by whoever had a spare hour.

Why this one is different

A README is pull. Somebody wants it, somebody opens it, the cost of the read is their attention. A context file is push. It is prepended to the working context every time an agent starts, every time a session compacts, every time a subagent spawns. The cost does not scale with how many people find it useful. It scales with how many times you run.

So the economics invert. A long README written once and read rarely is cheap. A long context file written once and read constantly is expensive, and it gets more expensive the more successful your agent programme becomes.

In February 2026 a group out of ETH Zurich put a number on it. Thibaud Gloaguen and colleagues built a benchmark they call CTXbench: 138 task instances drawn from 12 Python repositories that already had a developer committed AGENTS.md or CLAUDE.md at the root. They screened 5,694 pull requests to get there. They ran four agent configurations over it: Claude Code on Sonnet 4.5, Codex on GPT-5.2, Codex on GPT-5.1 mini, and Qwen Code on Qwen3-30b-coder served locally. Then they ran each task three ways: no context file, a model generated one, and the real one the developers had written.

The results are not what the file is sold on.

A model generated context file moved task success by about minus 0.5% on SWE-bench Lite and minus 2% on CTXbench. Neither result was significant. A developer written file moved it by plus 2.4% on average, p equal to 0.21, also not significant. The one comparison that cleared the bar was developer written against model generated, where the human file won by a margin the paper puts at 7%. Their own summary sentence is flat: “providing context files does not generally improve task success rates.”

The cost side was not ambiguous at all. Model generated files raised inference cost by roughly 20% on SWE-bench and 23% on CTXbench. Developer written files raised it by at most 19% and added 3.34 steps per task on average. The agents were not ignoring the files. The paper is explicit that “instructions in context files are well followed.” They read the instructions, then went and did more work: more tests, more greps, more files opened, more quality checks, much of it beside the point of the task in hand.

And the single most common section in these files, the repository overview, is the one the paper singles out as useless: “repository overviews, although popular and recommended by model providers, are not helpful.” Overviews did not meaningfully reduce the number of steps an agent took before it touched the file it actually needed to change.

What that costs in money

Gartner Peer Insights found in June 2026 that 23% of technology leaders are spending $200 to $500 per developer per month on tokens for coding agents, and 6% are spending over $2,000. DX puts enterprise Claude Code deployments at about $13 per active developer day, or $150 to $250 a month. Gartner’s Nitish Tyagi expects per developer token cost to go from $20 to $200 and in some cases to $2,000, and Gartner forecasts that by 2028 AI coding cost will exceed the average developer salary.

Take the conservative end. Call it $300 a month per developer. A 19% context tax is $57 per developer per month. Across forty engineers that is $27,360 a year, recurring, for a gain the measurement could not distinguish from zero.

That is my arithmetic, not Gartner’s. Run it on your own numbers. The point is that the number exists and it is not small, and I have not once seen it on a budget line or in an AI programme business case.

Three things the field data says

First, almost nobody has one. Research presented at the 23rd Mining Software Repositories conference in 2026 scanned 10,000 active repositories and found roughly 5% carried any AI context file at all. 466 had an AGENTS.md. So the practice everyone is writing about is a minority practice being adopted at speed, before anybody measured it.

Second, the files are written once and abandoned. In the deep analysis of that sample, 50% of the files had not been modified after the commit that created them. Another 23% were modified exactly once. A context file is a set of imperative instructions that an agent follows well. An abandoned one is a set of wrong instructions that an agent follows well. That is not a neutral state, it is worse than having no file, and the failure is silent because the agent never tells you it obeyed something false.

Third, the maintenance is real work and it compounds. An experience report published in February 2026 documents one developer building a 108,256 line C# simulation with Claude Code over 283 sessions and 70 days. The supporting context layer ended up at 54 files and about 26,200 lines, which is 24.2% of the line count of the product itself. Maintenance ran one to two hours a week. The author names the main failure mode without hedging: stale specifications produced conflicting code at least twice.

A quarter of your codebase, in prose, that nobody compiles and no test covers.

Where this breaks

The honest objections are good ones.

The ETH sample is 12 repositories and 138 tasks, Python only, and the repositories are small and recent by construction, because they had to already have a context file to qualify. A twenty year old monorepo with genuinely non obvious conventions is exactly the case where a file should earn its keep, and it is exactly the case the benchmark could not include. I would not call this settled.

A 2.4% lift that fails a significance test is not the same as no lift. It is an underpowered result. If a single failed agent run on a critical path costs you a day of senior time, paying 19% more per task to shift the odds is a trade most operators would take without blinking, and the benchmark has no way to price that asymmetry.

And the strongest objection is the one the paper cannot measure at all. Writing the file forces someone to write down the knowledge that was only in three people’s heads. That is worth doing whether or not an agent benefits, and the humans who join next year will benefit from it more than the model does.

I accept all three. None of them makes the file free. They change the answer to “is this worth buying”, which is a question you can only ask once you admit you are buying something.

What I would do on Monday

1. Measure your own tax before you argue about mine. Take ten representative tasks, run them twice with the same agent and model, once with the context file and once with it removed, and compare token cost per completed task. An afternoon of work and you will never have to take a blog post’s word for it again, including this one.

2. Delete the repository overview. It is the most common section in the corpus and the one section the research specifically found does not help. The agent can read your directory tree. It is faster at it than your prose is.

3. Put a hard ceiling on the file and make every new line compete for space. The observed average for AGENTS.md is 142 lines. CLAUDE.md averages 287 and Copilot instruction files average 310. Length here is a cost, not thoroughness.

4. Put an owner and a review date in the first three lines. Half of all these files are never touched again after the day they are born, and the instruction that was true in March is being executed with full confidence in October.

5. Move anything checkable out of prose. If the rule is “always run the linter before committing”, that belongs in a pre commit hook where it is enforced, not in a paragraph where it is re read and re billed a thousand times and still only sometimes obeyed.

The general rule I now apply: a line earns its place in the file only if the agent cannot infer it from the repository and it will still be true in ninety days. Everything else is a script, a test, or nothing.

The binder

That printed README is probably still in a cupboard somewhere. It was a bad document by any modern standard. It was out of date within a year and nobody noticed, because nobody opened it.

The new one gets opened every few minutes, forever, by something that believes every word.

Write it like it costs money. It does.

Most of what I write here started as somebody’s build cost going somewhere nobody forecast. If that is your week, grab a time.

The room goes quiet. Someone names a person who is not in the meeting. Someone else names a different person. Nobody names a date. We have just spent forty minutes agreeing a list of deliverables that everyone nodded at, and the first question about how that list gets decided empties the room.

That silence is the project. The deliverable list is not.

The argument

A scope document that lists what you will build is describing the output. Output is not what moves. Decisions move. So the document should list the decisions nobody has made yet, put one name against each, put a date on each, and state what the team does if the date passes. One page. Four sections. Not one deliverable in it.

That is the opposite of the standard advice. Every statement of work template, every work breakdown structure, every scope creep guide published this year tells you the same thing: describe the deliverables in more detail, write tighter acceptance criteria, and bolt a change control process on the side. I think that advice is aimed at the wrong failure.

The numbers say the failure moved

PMI published Pulse of the Profession on 22 May 2026. Ninety seven percent of project professionals managed at least one complex project in the prior year. Thirty one percent of those complex projects failed to achieve their originally intended scope of benefits, against 12 percent in the 2024 report. That is two and a half times in two years.

Now put that next to delivery performance, which barely moved at all. Arcidiacono’s 2025 update in the PM World Journal, published January 2026, compares two multi year datasets on IT project outcomes. The 2015 to 2017 window: 29 percent successful, 52 percent challenged, 19 percent failed. The 2020 to 2024 window: 31 percent successful, 50 percent challenged, 19 percent failed. Nine years, two points of movement, and the failure column did not move by a single point.

So delivery discipline is flat and benefit capture fell off a cliff. Whatever broke, it did not break in the part of the project that a deliverable list controls.

The PMI report says where it broke. Under value and alignment gaps, which hit 61 percent of complex projects, the largest single item is stakeholder decision delays at 34 percent. Budget overruns are 12 percent. Profit loss is 9 percent. Decision delay is bigger than both of those put together and then some. Every scope artefact on the market is built to police budget and deliverables. Almost none of them is built to police decision latency, which is the variable doing the damage.

There is a second number in the same report that I keep coming back to. Forty five percent of project professionals name multiple stakeholders across functions and geographies as a driver of complexity. Twenty seven percent of executives name the same thing. An eighteen point gap between the people who sign the scope document and the people who have to live inside it, on exactly the variable that produces decision delay. The document is written by the party that cannot see the constraint.

Speed is not the enemy of quality

The usual objection to all of this is that forcing decisions onto dates produces bad decisions. McKinsey surveyed more than 1,200 managers for its 2019 work on decision making. Respondents who reported that decisions were made fast were 1.98 times more likely to report that those decisions were high quality. Not a tradeoff. A correlation running the other way.

The same survey found 61 percent of managers saying at least half the time spent making decisions is ineffective, and only 34 percent saying their organisation made cross cutting decisions that were both good and timely. Cross cutting is the category every project sits in.

Read those two findings together and the change control process looks different. A change control board exists to slow a decision down so it can be examined. The evidence says slow decisions are not better decisions, they are just later ones, and the lateness is the thing killing benefit capture. The safeguard is the failure mode wearing a lanyard.

The one page

Four sections. It fits on a page because if it does not fit on a page nobody reads it in week six, which is the only week it matters.

One. The open decisions. Every decision not yet made that would change what gets built. One line each, written as a question with at least two real answers. Not “confirm the data model”. Instead: “do we write to the existing customer table or stand up a new one”. If it has only one answer, it is not a decision, it is a task, and it belongs somewhere else.

Two. One name. A person, not a function, not a committee, not “the steering group”. If two names appear, the decision is actually two decisions and you have not finished writing it. This section is where most kickoffs fall apart, because naming an owner in writing is a commitment and the room can feel it.

Three. The date and the default. The date the answer is needed, and the sentence describing what the team will build if that date passes without an answer. The default is the whole trick. It converts a blocked decision into a made one. It also removes the incentive to stall, because stalling now has a named consequence that the owner has already read.

Four. What is already out. The things explicitly not in scope, written as decisions that have been made, with the person who made them. This is the section that survives a change of sponsor, which is when every undocumented exclusion comes back.

There is a loop hiding inside the first section and it is the part that costs money. An unnamed decision does not stop the team. The team assumes an answer, builds on the assumption, and the assumption surfaces at a review where it is expensive to unwind. Then the same decision goes back into the queue, still unnamed. I have watched the same decision arrive at three consecutive steering meetings, get discussed each time, and get owned none of them.

Where this breaks

Four honest limits.

The change control evidence cuts against me. PMI’s own research says projects without formal change management are 35 percent more likely to exceed cost or miss deadlines. That is a real finding and I am arguing for less process at the point of change, not more. My position is narrower than it sounds: the change process is fine for changes, and useless for decisions that were never made in the first place. Those are different objects and most documents treat them as one.

The PMI decision delay figure is self reported by project professionals, who have an obvious interest in locating the blame one level above themselves. I read a survey of practitioners as evidence about executives. That is a weakness and I am not going to pretend otherwise.

The default mechanism assumes the team can actually proceed on a default. In regulated work, in anything touching patient data or client money, there are decisions where the only lawful default is stop. For those the section still helps, because it makes the stop visible and dated before it happens, but the mechanism is doing less work.

And the honest one about me. A one page document is easy to write and easy to like. It does not survive contact with a sponsor who will not put their name on anything, and there are organisations where the refusal to name an owner is the culture rather than an oversight. In those places this document does not fix the project. It just tells you early, in writing, that the project is not going to work, which is worth something but is not what I sold.

What I would do on Monday

1. Take the scope document for your largest running project. Count the deliverables. Then count the decisions that are named, dated and owned by one person. If the second number is zero, you have a wish list, not a scope.

2. Write the open decisions down as questions with two real answers each. Most teams find between six and twelve on a project of any size. Anything with one answer moves to the task list.

3. Put one name and one date against every line, out loud, in a meeting, with the names in the room. Do not accept a function. Do not accept two names.

4. Write the default for each. The sentence starts “if we have no answer by this date, we will build”. Circulate it. The objections you get back within a day are the real risk register.

5. Bring the page to every steering meeting and change only the dates. If a date moves twice, escalate the owner, not the decision.

The kickoff where I ask who has to say yes is still quiet. That has not changed. What changed is that I now write the silence down, put a date on it, and hand it back to the room before anyone has spent a dollar building anything.

I spend most of my week inside delivery organisations where the build is fine and the decisions are late. If you are about to sign a scope document that names forty deliverables and no owners, book a call first.

Writing a real one takes most of a week. You read everything the company has published. You sit with the people who do the actual work. You find the thing nobody has said out loud yet, and you write the plan that follows from it. That plan is the work. It is the most valuable thing I produce in any given month. And the convention in this industry is that I hand it to someone who has not yet decided to buy anything, for free, and then ask to be paid for the part that comes after.

I stopped doing that. Not out of principle. Out of arithmetic.

The thesis

A proposal was never a document. It was a costly signal. Thirty three hours of senior attention that could not be faked was the proof that you had understood the problem, and the buyer read the effort, not the pages. Generative AI made that effort cheap to counterfeit. A signal that is cheap to counterfeit carries no information. So the proposal still exists, it still gets written, and it no longer tells the buyer anything.

The arithmetic that made me stop

Loopio published its sixth annual RFP Response Trends and Benchmarks Report on 11 March 2026, from 1,533 response management professionals across more than seventeen industries. Read the numbers next to each other rather than one at a time.

The average organisation submitted 166 RFPs last year, up from 153. The average response took 33 hours, down from 35. Nearly 80% of teams used generative AI during 2025, ten percentage points more than the year before, and 62% used it to write specific answers.

So: 153 responses at 35 hours is 5,355 hours. 166 responses at 33 hours is 5,478 hours. The technology cut the unit cost of a proposal by 5.7% and the volume went up 8.5%. The total time these teams spent writing proposals did not fall. It rose by 123 hours.

That is Jevons paradox running inside a sales organisation. Make a thing cheaper to produce and you produce more of it, and the saving never reaches the P&L.

Now put the win rate on top. Loopio’s benchmark average across 2019 to 2026 is 45%. The current figure is 39%. Adoption of the tool that was supposed to help crossed 80% in the same window that the hit rate fell six points below its own seven year average.

Take the 61% that lose. That is 3,341 hours a year, in one company, producing documents nobody bought. At a 1,950 hour working year it is 1.7 full time people whose entire job is losing. Half of these teams already name bandwidth as their number one problem, which is the correct diagnosis of the wrong system.

What replaces it

The rule is one line. If the problem is already agreed in writing, I will quote a fixed scope for the first block of work. If it is not agreed, the diagnosis is the engagement, it is priced, it runs two weeks, and it ends with a document the buyer owns whether or not they ever hire me again. If they will not pay for the diagnosis, I decline the delivery, because a buyer who will not fund two weeks of thinking will not fund six months of change.

This is not a pricing trick. It changes who is holding the risk. A proposal asks a room to commit to a large decision on the strength of a document written by the person being paid. A paid diagnostic asks one person to commit to a small, bounded, reversible decision, and it produces the evidence the room needs to make the big one.

Why the room is the real constraint

Matt Dixon and Ted McKenna analysed 2.5 million recorded sales conversations for The JOLT Effect, using machine learning to isolate roughly 8,300 factors behind wins and losses. Between 40% and 60% of lost deals end in no decision. The driver is not preference for the status quo. It is fear of failure: the buyer wants the thing and cannot carry the personal risk of being the one who chose wrong.

A proposal does nothing about that. It is an argument for a decision, delivered to someone who is afraid of the decision. More pages make it worse.

Gartner surveyed 632 B2B buyers in August and September 2024 and found 74% of buying teams showing unhealthy conflict during the decision. Delainey Kirkwood put the group at five to sixteen people across as many as four functions. Groups that reach consensus are 2.5 times more likely to report a high quality deal. Content aimed at one individual reduced consensus by 59%.

That last figure is the one that ended proposals for me. The document is written to a champion. The decision is made by a committee that is already fighting. A paid diagnostic is the only format I have found where the committee is in the room while the conclusion is being formed, so the output arrives with their fingerprints on it instead of mine.

Where this breaks

Government and regulated procurement runs on unpaid written responses and no amount of principle changes that. If your revenue depends on tenders, you write tenders, and the only available move is to qualify harder before you start.

Loopio’s sample is people whose job title is response management, so it over represents companies where the RFP is the sales motion. The 33 hours may be elapsed time rather than person hours, and with nine contributors on an average response the real number could be far worse than the one I used. I have taken the conservative reading.

The win rate fall from 45% to 39% is not proof that AI caused it. More responses to lower quality opportunities would produce the same line.

And the honest limit: charging for the diagnosis requires enough demand to say no. I could not have done this at thirty. If you need the next engagement to make payroll, you will write the proposal, and you should. The method is downstream of the pipeline, not a substitute for it.

What I would do on Monday

1. Add up last year’s losing proposals. Count the hours, name the people, and put the number in front of whoever signs their invoices.

2. Write the two week diagnostic as a real product. Fixed fee, fixed dates, named output, and a sentence saying the client owns it outright.

3. Change the first question on the call from what do you need to who has to agree, and what are they arguing about. Then price the argument.

4. Stop sending anything longer than two pages to a buyer who has not paid you. If they need thirty pages to decide, the problem was never described properly.

5. Keep one exception list. Tenders, framework agreements, and the two or three relationships worth the free work. Everything else follows the rule.

The close

I still do that week of work. I still read everything, sit with the people who do the job, and find the thing nobody has said out loud. That part was always the value and it still is.

The only thing that changed is that it now has a price, a start date, and an invoice.

I spend most of my week being paid to find out what is actually wrong before anyone commits to fixing it. If you are about to ask three firms for a free plan, book a call instead.

The money arrived in the technology seat. Almost nobody announced it.

The thesis

The CTO job split in two this year. One half became capital allocation: deciding what gets funded, at what unit cost, and what gets stopped. The other half, the half whose authority was denominated in headcount, is being deleted by the same technology that delivered the money. Most people holding the title are still doing the second job and calling it the first.

What actually moved

Three things happened in about fourteen months, and they are usually reported separately.

The amount got large. Gartner put worldwide AI spending at $2.52 trillion for 2026 in its 15 January release, up 44% on $1.757 trillion in 2025. That is not a line item. In most large enterprises it is now the biggest discretionary number the technology function touches, and it is growing faster than the function that governs it.

The composition is hostile to a builder. Inside that $2.52 trillion, AI infrastructure is $1.366 trillion. AI services are $588.6 billion. AI software is $452.5 billion. AI models are $26.4 billion. AI data is $3.1 billion.

Divide the first by the last. For every dollar the world spends on AI data this year, it spends $441 on AI infrastructure.

I have not seen a capital allocation ratio like that survive contact with a board. Infrastructure is bought at a price three vendors set, and it reprices every time they do. Data is the only line in that list that compounds inside your company and cannot be bought by your competitor on the same terms. A capital allocator looks at 441 to 1 and asks whether that is the return maximising split. A delivery manager looks at 441 to 1 and approves the invoice, because approving invoices was never the part of the job anyone was measured on.

The org chart made a new seat. IBM’s Institute for Business Value surveyed 2,000 CEOs across 33 countries and 21 industries with Oxford Economics between February and April 2026. 76% of organisations now have a chief AI officer. Twelve months earlier it was 26%. In the same study, 77% said talent and technology leadership roles are converging, and 85% said every functional leader has to become a technology expert inside their own domain.

Read those two findings together. The mandate is leaving the technology seat at the same time the money is arriving in it. Whoever can price a decision keeps both. Whoever cannot keeps neither.

What an allocator has to say out loud

A delivery manager is measured on shipping. An allocator has to state three things before spending anything, and I have watched a lot of capable technology leaders fail to state any of the three for AI.

The unit. One sentence: what is one unit of output from this, and what does it cost today. Not productivity. A countable thing with a dollar figure attached to it.

The hurdle. What return clears. The FinOps survey found a growing number of organisations now requiring AI investment to be self funded out of efficiency gains. That is a hurdle rate. It was set by finance, not by technology. If you did not write it, you are not the allocator. You are the applicant.

The kill criterion. The date and the number that ends it. Deloitte surveyed 3,235 business and technology leaders across 24 countries for its 2026 State of AI in the Enterprise report. Only 25% had moved 40% or more of their AI pilots into production. Only 21% reported mature governance for agentic AI. A portfolio where three quarters of the positions never reach production and four fifths carry no governance is not underperforming. It is unmanaged.

The half being deleted

Gergely Orosz published a piece on 18 August 2026 on engineering leaders taking career breaks. He interviewed roughly twenty of them. Six of ten CTO level contacts told him they were on the way out. The reasons he recorded are worth reading in order: unrealistic AI expectations, cost cuts of 20 to 50%, equity sitting behind a preference stack, and smaller teams reducing the need for the leadership layer at all. Several said they would rather work fractionally than take another full time seat.

I have a direct interest in that last sentence. I do fractional CTO work through PADISO and enterprise AI delivery through Brightlume, so the pattern Orosz describes is also my order book. I am not neutral about it. I also think he is describing a structural change rather than a mood. If your authority came from managing 60 engineers and the organisation now needs 25, the authority left with the 35. Seniority does not replace it. The people leaving are the ones who worked that out first.

Where this breaks

Four honest limits.

Gartner’s category boundaries are doing a lot of work in my 441 to 1 figure. AI data at $3.1 billion almost certainly excludes the data engineering labour, the warehouse spend and the integration work already booked under other lines. The real ratio is better than 441 to 1. The direction holds. The magnitude is arguable, and I would not put that number in a board pack without the footnote attached.

The chief AI officer figure is self reported titles collected from CEOs. A title can be created with no budget behind it. Twenty six to seventy six in twelve months is also too fast to be a stable structure, and some of those seats will not exist in 2028. What it proves is that boards decided the technology seat as it stood was not sufficient. It does not prove they built the right replacement.

Orosz’s sample is about twenty people and he says so himself. It is a signal from a well connected observer, not a measurement.

And the split does not apply below a certain size. Under roughly fifty engineers the allocator and the builder are the same person on the same day, and pretending otherwise produces a CTO who writes memos while the product stalls. This is a problem of scale. It arrives at the point where the AI bill starts to rival the engineering payroll.

What I would do on Monday

1. Write the unit for every AI initiative you fund. One sentence each: the countable output, and its cost today. If you cannot write it in a sentence, you are not funding a position, you are funding an activity.

2. Find out who set the hurdle. If AI at your company has to pay for itself out of efficiency gains, name the efficiency line and the quarter it lands in. If finance wrote that and you did not, fix the order.

3. Write the kill criterion before the next invoice. A date and a number. Put it in the same document as the business case, not in a review deck six months later.

4. Pull last quarter’s AI spend apart into infrastructure, licences, models and data, and compute your own ratio. Compare it to 441 to 1. If yours is worse, you have an allocation problem, not a technology problem.

5. If a chief AI officer was appointed at your company in the last twelve months, find out this week whether they hold the pen or the press release. The answer tells you which half of the job you still have.

I built D30 to pull three statement fact files out of ASX annual reports instead of hiring analysts to read them, because one of those options has a unit cost that falls every year and the other has one that rises. That was a capital decision taken from a technology seat. It is the only kind of decision that seat gets judged on from here.

The FinOps Foundation changed one word. Cloud became Technology. It reads like housekeeping. It is a charter, and charters get written after the power has already moved.

Brightlume does this work with enterprise teams. If the gap between the AI pilot and the P&L is the problem you have, talk to me.

So when a founder asks me in week one what I think is wrong with his engineering organisation, I tell him I do not have a view yet.

That answer has cost me work. I keep giving it, because 43 hours is the entire budget and I will not spend it confirming what the room already believes.

The thesis

The first 30 days of a fractional engagement is not diagnosis. It is instrumentation.

You cannot find a delivery constraint by asking the people inside it. They will report the constraint they personally feel, which is a real thing and a different thing. My job in month one is to leave four instruments running and a dated record of what everyone said before the instruments existed. The diagnosis is what the gap between those two says on day 31.

Why the interviews will lie to you, politely

In July 2025 METR ran the study that should have ended this argument. Sixteen experienced open source developers, 246 real issues on repositories they already maintained, averaging over 22,000 stars and a million lines of code. Screen recorded. Paid $150 an hour. Before starting, the developers forecast that AI tooling would make them 24% faster.

They were 19% slower.

The part that matters for month one is what happened afterwards. Having just been measured, on their own codebases, doing their own work, the same developers still estimated that AI had sped them up by about 20%. That is a 39 point gap between what a room of expert practitioners believed about their own delivery time and what a stopwatch recorded.

Nobody in that study was lying. Self report measures effort. It does not measure duration. Those two came apart in 2025 and they have not come back together.

Now put that against what the industry actually reports. DORA surveyed nearly 5,000 technology professionals for the 2025 State of DevOps report, with more than 100 hours of qualitative work behind it. 90% use AI at work. More than 80% believe it has made them more productive. 30% have little or no confidence in the code it produces. DORA found AI positively related to delivery throughput and still negatively related to delivery stability.

Both of those are true at once, which is precisely why an interview cannot resolve them.

What the telemetry says instead

The 2026 AI Engineering Report from Faros is the closest thing we have to an answer, because it is not a survey. It is two years of telemetry across 22,000 developers and more than 4,000 teams.

At the top of the pipe, the story people tell is correct. Merge rate per developer is up 16.2%. Task throughput per developer is up 33.7%. Epics per developer are up 66%.

At the bottom of the pipe it inverts. Median time in review is up 441.5%. Time to first review is up 156.6%. Merges shipped with no review at all are up 31.3%. Code churn is up 861%. Monthly incidents are up 57.9%, and incidents per pull request are up 242.7%. Bugs per developer are up 54%, against 9% the year before.

Read those two paragraphs again as one sentence. Everything a person can feel got faster. Everything only a system can see got worse. An interview picks up the first list and cannot see the second, and that is the entire reason I refuse to give an opinion in week one.

The four instruments

None of these need a vendor, a budget line, or a steering committee. All four come out of git, the deploy log and the incident channel, and I ask for read only access to all three on day one, before the kickoff deck.

One. Lead time from first commit to production. Not from ticket creation, which measures how a team fills in Jira. First commit to live measures the system. I want the distribution and the long tail, never the average, because the average is where a two week outlier goes to hide.

Two. Review latency and the unreviewed merge rate. This is the surface that broke in 2026 and almost nobody watches it. Two numbers: median hours in review, and the percentage of merges that reached production with no human review at all.

Three. Rework. Churn, restarts, and items stalled more than seven days. This separates shipped from finished. A team can be shipping 33% more and finishing less, and the roadmap will show only the first half.

Four. Incidents per merged change. Not incidents per month. A team reporting incidents up a bit is reporting the numerator while the denominator moved underneath it. In the Faros data the monthly count moved 57.9% and the ratio moved 242.7%. Those are the same organisation described two ways, and only one of them is a measurement.

Three things the instruments say that the room never does

”We are much faster now.” Usually true, and usually true only at merge. The change is real and it stops at the review queue. I have never once heard a team volunteer their unreviewed merge rate, because nobody computes it.

”Quality is holding.” Held against what. Flat incidents against flat volume is stability. Flat incidents against a 16.2% higher merge rate is an improvement worth celebrating. Rising incidents against rising volume is the normal case and it is not a crisis, but it is also not what holding means.

”The bottleneck is the platform team.” Sometimes. It is also the single most reported answer I get, from every seat, in every engagement, and it is exactly the shape of answer METR showed practitioners get wrong about themselves.

I learned this the expensive way on my own product rather than a client’s. I built the extraction engine for D30 first and the articulation gates second, which is the wrong order. The gates went in and immediately caught a share count that was out by 31 units against the store, on a workbook I had already read and believed. I would have signed that. Now the instrument goes in before the opinion, in my own tooling and in other people’s companies.

Where this breaks

Three ways, and I have hit all of them.

The first: not every engagement is diagnostic. If the brief is ship the migration by 30 November, spending 30 days instrumenting is a sophisticated way to miss the date. This rule applies when the brief is we are slow or we do not know why this hurts. When the brief names a deliverable, go and deliver it.

The second: instruments need events. In an organisation deploying quarterly, by hand, with incidents tracked in somebody’s inbox, 30 days of measurement produces almost no data points. There you are back to interviews and a stopwatch, and the honest move is to say so out loud rather than dress up a thin sample as evidence.

The third, and the one that actually bites: a number that lands on day 31 with no relationship behind it reads as an audit. Audited teams optimise the number, and then the instrument is worthless. So the 30 days is also 30 days of earning the right to publish what the instruments found. Skip that and the measurement survives while the mandate does not.

One more limit worth naming. The METR result is 16 developers on mature open source codebases with early 2025 tooling. The coefficient does not transfer to your company. The direction does, and the direction is the only part I use.

What I would do on Monday

1. Ask for read only access to git, the deploy or CI log, and the incident channel. If that takes more than five working days to arrive, you have your first finding, and it is about the organisation rather than the tooling.

2. Pull lead time from first commit to production for the last 90 days. Plot the distribution. Look at the slowest decile only.

3. Compute two numbers nobody has: median hours in review, and the share of merges that shipped unreviewed.

4. Compute incidents per merged change for the last two quarters. Compare it to incidents per month and see whether they tell the same story.

5. On day one, write down what the room says the constraint is. Date it. Do not share it. On day 31 put it beside the instruments. That comparison is the deliverable, and it is worth more than either half on its own.

Close

Forty three hours is not enough to fix an engineering organisation. It is exactly enough to stop guessing about one.

The question I refuse in week one is the same question I can answer on day 31 with a number instead of a view. Clients think they are paying for my opinion. What they are actually paying for is the 30 days in which I do not have one.

Most of what I write about here started as a client problem. If you have one, bring it to me.

I have priced this work three ways: by the hour, by the retained day, and by the decision. Two of those are wrong and I used both. Both price my attendance, and attendance is the input that is deflating fastest right now. The decision is the only unit that held its value, because the cost of getting a decision wrong did not fall at all.

The entire market is denominated in time

Go and read the published benchmarks. Every one of them prices a calendar.

Go Fractional’s rate page puts the median fractional CTO ask at $220 an hour, with the middle half of the market between $175 and $250. Employers post $136. Talent asks $221. That $85 gap is the whole negotiation. The typical engagement is 16 hours a week, roughly 40% of a full-time week, which lands at about $14,000 a month with retainers starting near $11,200.

Tristella’s guide, published 1 July 2026, tiers it the same way: light advisory 10 to 15 hours at $4,000 to $8,000, standard fractional 20 to 40 hours at $8,000 to $15,000, deep fractional 40 to 60 hours at $15,000 to $25,000 and up. Kompella’s 2026 guide tiers by days instead of hours: advisory at one day a week for $8,000 to $10,000, fractional at two days for $15,000 to $18,000, embedded at three or more days for $25,000 to $30,000. It notes that most B2B SaaS engagements settle at $15,000 a month for two days a week.

Read those tiers again. Not one of them describes a result. They describe a diary.

What each model does to the conversation

Hourly billing punishes the thing you are selling. I am hired because I have seen the failure mode before. Recognition is instant. Under hourly, instant recognition is a small invoice, so the honest expert is paid least for the moment they were most useful. Every efficiency gain, every tool, every year of pattern library, converts directly into a smaller bill. You cannot fix that with a higher rate, because the rate has a ceiling the market publishes and the hours do not have a floor.

The retainer is better and it fails differently. You sell two days a week for $15,000 and the first month is fine. Then the finance lead asks what they got for the money. The truthful answer is eight days. Eight days is not a result, so you start manufacturing evidence of presence. Standups you did not need to be in. A weekly deck. Slack responsiveness as a performance. The retainer quietly converts a senior operator into an attendance record, and the moment the client’s budget tightens, an attendance record is the easiest line to cut.

Both models have the same defect. They price the input. In 2026 the input is the part collapsing in cost, and the client knows it.

The third model

The market already has the shape and misnames it. Kompella’s smallest tier is project pricing: a tech debt audit at $15,000 to $25,000, a 90 day plan at $30,000 to $50,000, pre-fundraise preparation at $40,000 to $75,000, M&A integration at $50,000 to $100,000 and up. That is closer, but a project is still a scope of work. A decision is different. A decision has a date, one or two viable options, and a cost of being wrong that somebody can name.

Four decisions make up most of what I actually get hired for. Build, buy, or agency. The platform migration go or no go. The pre-raise architecture answer, which in 2026 is really the question of what happens to gross margin when the model gets cheaper. And the diligence verdict on somebody else’s technology.

Each one has a number attached to being wrong, and the number is not $15,000 a month. That is what the fee attaches to, along with the artefact that outlives the engagement: the one page scope, the model, the gate list, the thing the client still has after I leave.

This is not a theory I applied to consulting and nowhere else. D30 is forensic extraction over ASX filings, and the fee is the fact file and the eight articulation gates, not the hours spent reading the PDF. That is deliberate: the model that reads the document is replaceable and getting cheaper, and pricing the reading would have been pricing the part that goes to zero. D23 sells managed Apache Superset, where nobody pays for the software because the software is free. They pay for it to be run correctly. Same logic, applied to me.

The largest firms in the world made the same move this year

McKinsey now ties about 25% of its global fees to outcomes rather than time, reported by the Wall Street Journal on 29 June 2026. In the same period its internal assistant, Lilli, runs over 500,000 prompts a month and its consultants report time savings on knowledge work of up to 30%. BCG puts AI and tech-enabled work at roughly 20% of 2024 revenue heading toward 40% this year. Bain has it near 30% and climbing toward half.

Treat those as directional. They come from firm media events and investor briefings, not audited disclosure, and every one of them is a marketing number as much as an operating one. The direction still matters. The firms with the most to lose from abandoning the billable hour moved a quarter of their fee base off it in the same year their own tooling cut a third off the work. That is not two unrelated events.

Where this breaks

Decision pricing needs a decision. Plenty of engagements are honest capability rental: the team is competent and simply has no senior person in the room, and they need one every week for a year. There is no dated call to attach a fee to. The retainer is the correct instrument there, and pretending otherwise is a pricing model looking for a problem. Cap it and give it an exit date so it does not become tenure.

It also requires deal flow you may not have. Quoting a fee that is unanchored from your cost only works if you can absorb a no. If one client is more than a third of your revenue, you will not hold the line, and a published day rate is the more honest thing to sell.

The hardest problem is attribution. An hourly invoice settles in 30 days and nobody argues about whether the hours happened. A decision proves itself 14 months later, by which point the client remembers the outcome and not who made the call. So the fee has to land at the moment of the decision, not at the moment of the result. Charge for the outcome and you have written the client a free option on your own judgement.

What I would do on Monday

1. Take your last three invoices and divide each by the hours behind it. Then write down, in dollars, what the client’s cost of being wrong was on the largest call in that same period. The ratio is the argument.

2. Change one line in the proposal template. Delete “days per week” and put in the name of the decision and the date it has to be made by.

3. Name the artefact. If nothing survives your last day, you sold attendance and the invoice was correct.

4. Put a cap and an exit date on every retainer you currently run. Not to end them. To make renewal a decision instead of a default.

5. Stop answering the day rate question first. Ask what decision is waiting on you, and quote the answer to that.

The question still arrives in the first ten minutes. What is my day rate. I answer with a number now, and it is not per day.

I write this from the PADISO seat. If you need a CTO who has shipped, raised, and cleaned up after both, book a call.

Three vendors. Three different units of account. It is Intercom’s own comparison page, so read the framing with the suspicion it deserves. The prices are still the prices.

I read it twice. Then I opened the build versus buy model I have used for a decade and realised there is no cell to put any of that in.

The thesis

Cost is no longer the deciding variable in build versus buy. Build got cheap enough that the number stopped being decisive. Buy stopped producing a number you can forecast at all. The variable that replaced cost is reversibility: how many days it takes to undo the choice you just made.

What actually changed

Two things moved at once, in opposite directions.

Build got cheap at the front and expensive at the back. New Relic surveyed 200 US technology decision makers, manager level and above, published 10 June 2026.

67% said AI now generates or significantly refactors between 51% and 75% of their weekly code output. Google has publicly put its own figure near 75%, Microsoft around 30%, GitHub Copilot 46%. Whatever the real number inside your organisation, the first working version of an internal tool is no longer a two-quarter project with a business case attached.

The same survey carries the other half. 78% reported a measurable spike in production incidents tied to AI-written code. 86% saw senior engineers spending more time firefighting. 74% said at least a quarter of AI-written code needed significant rework after deployment. The report puts AI-generated code at roughly 1.7 times more critical runtime issues.

The build got cheap. The run got expensive. That is a different shape of decision, not a smaller one.

Buy stopped being a fixed price. Zylo’s 2026 SaaS Management Index covers 40 million licences and $75 billion in spend under management. Median SaaS spend per employee: $9,455. Licences sitting unused: 36%. AI-native application spend in organisations above 10,000 people: up 393% year on year. Large enterprises are adding 21 applications a month.

The figure that matters most sits in their survey of 218 IT leaders. 78% reported unexpected charges from consumption-based or AI pricing models. 61% were forced to cut projects because of unplanned SaaS cost increases.

Read that second number again. Three in five technology organisations killed work they had already committed to, because a vendor bill landed above forecast. That is not a procurement problem. That is a budget that has stopped being a budget.

For scale: Gartner put worldwide software spend at $1,468 billion for 2026, growing 15.5%, against IT services at $1,570 billion growing 5.3%. The money is moving into the category that just became unforecastable.

Three cases

D23.io. I run a managed Apache Superset service. Superset is Apache-licensed and costs nothing to acquire. Nobody has ever paid me for the software. They pay for version upgrades that do not break their dashboards, for someone answering the phone when a query melts a warehouse, for the security posture. The decision there was never about build cost, because build cost was zero. It was about who carries the run. That is the question the cost comparison never asks.

D30. I built forensic extraction over ASX annual reports myself rather than buying a data feed. Not because I could not buy one. Because the extraction path and the articulation gates are the product. Buying that layer means renting the only part a customer cannot get somewhere else, from a supplier who can reprice it annually. When a capability sits directly on your differentiated data, buying it hands someone else pricing power over your margin.

The support agent, priced out. Take 40,000 support conversations a year. At Agentforce’s $2 per conversation that is $80,000 before platform fees and before implementation. At Fin’s 99 cents per resolved outcome your cost depends entirely on resolution rate, which you do not know until you are live. At Zendesk’s committed $1.20 it is $48,000, if your volume matches the commitment you signed. Same capability, three cost curves, none of them modellable over three years without traffic data you do not have yet. Zendesk also absorbed its Advanced AI add-on into all Suite plans in May 2026, which moved the line again mid-year.

That is the cell that does not exist in the spreadsheet.

Where this breaks

The reversibility test is a luxury of small commitments.

If the capability is your system of record, nothing is reversible. Moving a general ledger, a core banking platform or a policy administration system is a two-year programme whichever way you originally decided, and for those, cost and vendor viability come straight back to the top of the list. Do not apply my test to a core system.

The bigger problem is the assumption underneath all of it: that build actually did get cheap for your team. METR ran a randomised controlled trial with 16 experienced open-source developers across 246 real issues, on repositories they had contributed to for years, averaging over a million lines of code and 22,000 stars. With AI tools available, they were 19% slower. They had expected to be 24% faster. After finishing, they still believed AI had made them 20% faster.

That result should sit badly with anyone quoting the 67% figure, including me. On a mature codebase, with senior people who already hold the context in their heads, build cost may not have fallen at all. It may have risen while everybody felt quicker. If that describes your team, this thesis weakens a lot, and the honest move is to measure your own cycle time before you rearrange policy around somebody else’s survey.

What I would do on Monday

1. Pull twelve months of vendor invoices and compute variance, not average. Any line above 20% month-on-month variance has become a risk decision rather than a cost decision. Those are your first candidates to cap or bring in-house.

2. Write the exit paragraph before you sign. Ninety days, where the data goes, in what format, who does the work, what it costs. If nobody in the room can write that paragraph, you are not buying a tool. You are merging with a vendor.

3. Put a hard ceiling on every usage-priced contract, with a stop and not an alert. An alert tells you after the money has gone. Ask for the ceiling in the contract, in writing, and expect resistance.

4. For anything you build, name the person who owns it in eighteen months. No name, no build. What you have otherwise is a prototype and a future problem, and the New Relic firefighting numbers tell you who inherits it.

5. Run a licence utilisation report this week. If 36% is anywhere near right for you, you are already paying monthly for a buy decision that went wrong. That money is the budget for whatever you decide next.

Close

I went back to the model and deleted the cost comparison tab.

What replaced it is one column: days to undo this. Under 90, buy it and cap the term at twelve months. Over 90, it either touches the data that makes you money, in which case build it and own the path, or it does not, in which case put an agency on it under a six month cap and keep the repository in your own organisation.

The spreadsheet is smaller now. It is also the first version of it that survives contact with a pricing page.

Most of what I write about here started as a client problem. If you have one, bring it to me.

Both models offer alternatives to hiring a full-time Chief Technology Officer, but they operate under distinctly different premises. Understanding the nuances between these two approaches—and when to deploy each—is essential for leaders making strategic technology decisions. Understanding the trade-offs in the fractional vs interim CTO comparison helps align leadership to business goals.

In this comprehensive guide, we'll break down the fractional vs interim CTO comparison, explore the real-world implications of each model, and help you determine which leadership approach aligns with your organization's current stage, budget, and strategic priorities.

Understanding the Core Distinction: Fractional vs Interim CTO

The fundamental difference between a fractional CTO and an interim CTO lies in duration, intensity, and strategic intent. While both models bring senior technical leadership without the cost and commitment of a full-time hire, they serve different organizational needs. A careful fractional vs interim CTO analysis will consider duration, intensity, and long-term strategic intent.

A fractional CTO is a long-term, ongoing engagement where a senior technologist dedicates a portion of their time—typically 10–40 hours per week—to your organization over an extended period (often 6–24+ months or indefinitely). The fractional model emphasizes strategic continuity, ongoing mentorship, and building sustainable technical practices. It's designed for organizations that need consistent leadership presence but don't require a full-time executive commitment.

An interim CTO, by contrast, is a temporary, intensive engagement typically lasting 3–12 months. An interim CTO is brought in to handle a specific transition, crisis, or project—such as standing up a new technology platform, leading through an acquisition, stabilizing a failing engineering organization, or bridging a leadership gap during a permanent hire search. The interim model emphasizes rapid execution, hands-on problem-solving, and transition planning.

As explained in resources like Fractional CTO vs Interim CTO: Which One Do You Actually Need?, the choice hinges on whether your organization needs ongoing strategic guidance (fractional) or time-bound operational intervention (interim).

Time Commitment and Engagement Duration

Photo by Dylan Gillis on Unsplash

One of the most visible differences between these two models is how much time the executive dedicates to your organization and for how long. Any board evaluating fractional vs interim CTO options should map hours and duration to desired outcomes.

Fractional CTO Time Commitment:

Fractional CTOs typically work 10–40 hours per week, though some arrangements flex based on seasonal needs or project intensity. The engagement is open-ended and renewable, often spanning 6 months to several years. Many fractional relationships become semi-permanent, evolving as the organization's needs change.

This part-time structure means the fractional CTO is simultaneously serving other clients or maintaining a portfolio of responsibilities. This isn't a limitation—it's often a feature. A fractional CTO brings cross-industry insights, exposure to multiple technology stacks, and battle-tested patterns from other organizations.

The fractional model works particularly well for organizations that need consistent guidance but don't have the budget or workload to justify a full-time executive. As detailed in Fractional CTO vs Full Time CTO: Which One 10M Company Actually Needs, many companies in the $5M–$50M revenue range find fractional engagement the optimal balance.

Interim CTO Time Commitment:

Interim CTOs typically operate at full-time intensity (40–60+ hours per week) for a defined duration. The engagement is time-bound and mission-focused, with clear start and end dates or trigger events (e.g., "until the new platform launches" or "until a permanent CTO is hired").

Because the interim role is temporary and intensive, the interim CTO is often fully dedicated to your organization during the engagement. This allows for deep immersion in your challenges, faster decision-making, and the ability to implement significant changes within a compressed timeframe.

Interim engagements are ideal when you need someone to "own the room," make tough technical decisions, and drive execution without the distraction of other commitments. Interim CTO vs Fractional CTO (2026): Which Do You Need? emphasizes that interim CTOs excel in crisis stabilization and major transitions.

Cost Structure and Financial Implications

Photo by Christian Velitchkov on Unsplash

Cost is often the primary driver of the fractional vs interim CTO decision, but the financial picture is more nuanced than simple hourly rates. When evaluating budgets, compare total cost and impact in a fractional vs interim CTO analysis rather than focusing solely on hourly rates.

Fractional CTO Costs:

Fractional CTOs typically charge via retainer-based models, often ranging from $5,000–$20,000+ per month depending on seniority, location, and scope. Some fractional arrangements use hourly rates ($150–$400+ per hour) or equity arrangements for early-stage startups.

Because fractional engagement is part-time and ongoing, the total investment is spread over a longer period. However, the cumulative cost over 12–24 months can be substantial. The advantage is predictability and flexibility—you know the monthly cost, and you can adjust hours or scope as needs evolve.

As explored in Fractional CTO Economics: Hours, Retainers, Equity, fractional arrangements often include equity components for early-stage companies, aligning incentives and reducing cash outlay.

Interim CTO Costs:

Interim CTOs typically command higher daily or weekly rates than fractional CTOs—often $3,000–$10,000+ per day or $15,000–$50,000+ per week—reflecting the intensity, temporary nature, and specialized expertise required.

However, because the engagement is time-bound (typically 3–12 months), the total cost is front-loaded and finite. You know upfront that you're committing to a 6-month engagement at $X per week, for a total investment of $Y. There's no open-ended commitment.

Interim engagements are often more expensive per unit of time but less expensive in total than a full-time hire (which includes salary, benefits, equity, and severance). For a specific, bounded problem, the interim model can be highly cost-effective.

As detailed in Pricing Fractional CTO Engagement: Day Rates, Retainers, Equity, organizations should evaluate total cost of engagement, not just hourly rates.

Strategic Continuity vs. Rapid Execution

Photo by Luke Chesser on Unsplash

Beyond time and cost, fractional and interim CTOs differ fundamentally in their strategic posture. Your product roadmap often drives whether you need fractional vs interim CTO guidance.

Fractional CTO: Strategic Continuity

The fractional model is built for long-term strategic thinking and sustainable change. Because the fractional CTO remains engaged over months or years, they:

• Build institutional knowledge about your technology, team, and business strategy

• Mentor your internal engineering leaders over time, raising organizational capability

• Implement sustainable practices (architecture patterns, security controls, development processes) that outlast the engagement

• Evolve strategy as the business grows, pivoting technical direction as needed

• Serve as a trusted advisor to the board, CEO, and executive team on technology decisions

The fractional model assumes that your organization benefits from consistent, evolving guidance. This is ideal for companies scaling engineering teams, modernizing technology stacks, or embedding AI and analytics capabilities. As outlined in The Fractional CTO Engagement Model: How to Structure the First 90 Days, fractional engagements thrive when structured with clear 90-day milestones that feed into longer-term strategy.

Interim CTO: Rapid Execution

The interim model is optimized for fast, decisive action on a bounded problem. An interim CTO excels at:

• Crisis stabilization: Stopping the bleeding when engineering is in chaos

• Rapid implementation: Standing up new platforms, migrating systems, or launching new capabilities in compressed timeframes

• Leadership transitions: Bridging the gap between departing and incoming permanent CTOs

• Specific projects: Leading a major initiative (e.g., cloud migration, AI integration) to completion

• Tough decisions: Making unpopular but necessary choices (e.g., sunsetting legacy systems, restructuring teams)

Interim CTOs can move faster because they're not managing the long-term consequences—they're focused on solving the immediate problem and transitioning the solution to permanent leadership. Interim CTO Carve-Outs: Standing Up Technology highlights how interim CTOs excel at well-defined technical carve-outs.

Depth of Involvement and Hands-On Leadership

Another critical distinction is the depth of hands-on involvement and the breadth of responsibilities each model typically assumes. Decide early in a fractional vs interim CTO discussion how much operational ownership you're willing to transfer.

Fractional CTO Involvement:

Fractional CTOs are often strategic advisors with selective hands-on involvement. They might spend 60% of their time on strategy, architecture, and mentorship, and 40% on hands-on coding, technical reviews, or specific problem-solving.

Because fractional CTOs are part-time, they're not typically managing day-to-day operations or attending every meeting. Instead, they focus on:

• High-level technical strategy and roadmap

• Architecture decisions and technical debt management

• Hiring and team development

• Board-level technology updates

• Specific technical challenges or mentoring sessions

This selective involvement means the fractional CTO is a force multiplier for your existing team, not a replacement for operational leadership. Organizations with fractional CTOs still need strong internal engineering leadership (VP Engineering, Engineering Managers) to handle day-to-day execution.

Interim CTO Involvement:

Interim CTOs are typically fully embedded and hands-on. They attend all relevant meetings, make day-to-day technical decisions, and often code or directly oversee critical work.

Because the interim engagement is temporary and intensive, interim CTOs often:

• Own the full scope of technology leadership during their tenure

• Make and implement major decisions without extensive consensus-building

• Directly execute on critical technical work, not just oversee it

• Establish new processes, tools, and standards that the permanent team will inherit

• Document and transition their work to ensure continuity after departure

The interim model works because the organization knows it's temporary—they can tolerate a more autocratic, directive leadership style if it means solving the crisis or completing the transition.

Organizational Readiness and Internal Team Dynamics

The choice between fractional and interim also depends on the maturity and readiness of your existing team. Leadership should run a fractional vs interim CTO readiness assessment to determine internal team capability and governance gaps.

Fractional CTO Fit:

The fractional model works best when your organization has:

• A capable internal engineering team that can execute day-to-day

• Clear strategic direction (even if technical strategy needs refinement)

• Stable operations (not in crisis mode)

• Willingness to invest in long-term capability building

Fractional CTOs amplify existing strengths. If your team is already functional but needs strategic direction, fractional engagement is ideal. As discussed in Building Engineering Team Fractional CTO, fractional CTOs excel at scaling teams and establishing sustainable engineering cultures.

Interim CTO Fit:

The interim model is appropriate when:

• Your organization is in crisis (engineering chaos, failed projects, departing CTO)

• You need rapid, decisive action on a bounded problem

• Your internal team needs external authority to implement hard changes

• You have a clear transition plan (hiring a permanent CTO, promoting from within, or shifting to fractional)

Interim CTOs are often brought in precisely because the internal team can't or won't solve the problem alone. The interim leader brings external authority and fresh perspective.

Scope and Responsibilities

The scope of responsibilities also differs significantly between the two models.

Fractional CTO Scope:

Fractional engagements typically focus on strategic and architectural domains, such as:

• Technology strategy and roadmap

• Architecture and systems design

• Engineering culture and hiring

• Vendor and tooling decisions

• Board-level technology guidance

• Specific technical mentoring or code reviews

Fractional CTOs often have a well-defined scope document that clarifies what's in and out of the engagement. As detailed in Fractional CTO Scope Document: Padiso Template, clear scope prevents scope creep and ensures alignment on expectations.

Interim CTO Scope:

Interim engagements often have a broader, more operational scope, including:

• Full technology leadership and decision-making

• Day-to-day team management and performance

• Project execution and delivery

• Crisis stabilization and operational fixes

• Hiring and team restructuring

• Vendor management and procurement

• Board reporting and stakeholder communication

Interim CTOs often have a mission statement rather than a detailed scope—e.g., "Stabilize engineering and launch the new platform by Q3." The interim leader has more autonomy to define and redefine scope as conditions change.

Transition and Exit Planning

How each model ends is also fundamentally different. Exit plans differ significantly in any fractional vs interim CTO engagement, so document handoff processes accordingly.

Fractional CTO Transition:

Fractional engagements can transition smoothly to:

• Continued fractional relationship (ongoing advisory)

• Full-time CTO hire (fractional CTO mentors the new permanent hire)

• Reduced fractional engagement (shifting to office hours or quarterly check-ins)

• Graduation (the organization is ready to operate independently)

Because fractional relationships are built on strategic mentorship and capability building, the transition is often gradual and planned. As outlined in When Fractional CTO Engagements Fail: How to Fix Them, successful fractional engagements include clear milestones and transition criteria.

Interim CTO Transition:

Interim engagements have a predetermined end state, such as:

• Permanent CTO hire (interim CTO onboards the new permanent leader)

• Promotion from within (interim CTO mentors and transitions to internal leader)

• Return to fractional or advisory model (if the crisis is resolved)

• Engagement conclusion (problem solved, transition complete)

Interim transitions are typically structured and documented. The interim CTO is responsible for ensuring that their work, decisions, and institutional knowledge are transferred to the permanent team. As discussed in Interim CTO Carve-Outs: Standing Up Technology, successful interim engagements include explicit transition planning from day one.

Use Cases: When to Choose Fractional

Fractional CTO engagements are ideal for:

Scaling Startups and Growth-Stage Companies

Companies in the $5M–$50M revenue range often lack the budget for a full-time CTO but need consistent technical leadership as they scale. A fractional CTO can provide 15–25 hours per week of strategic guidance, hiring support, and architecture decisions without the $250K+ annual cost of a full-time executive. If you can't staff a full-time executive, a fractional vs interim CTO decision often resolves in favor of fractional for growth and mentorship. As explored in Fractional CTO vs Full Time CTO: Which One 10M Company Actually Needs, the fractional model aligns perfectly with this stage.

Non-Technical Founders

Founders without technical backgrounds benefit enormously from fractional CTOs who can translate between engineering and business, mentor the VP Engineering, and help the founder understand technology trade-offs. As detailed in Fractional CTO or Technical Co-Founder: Which Fits a Non-Technical Founder, fractional CTOs are often the right choice for non-technical founders scaling beyond the initial product phase.

AI and Analytics Integration

Organizations embedding AI capabilities, autonomous agents, or embedded analytics (e.g., Apache Superset + ClickHouse) benefit from fractional CTO guidance on architecture, vendor selection, and team structure. The fractional model allows for ongoing mentorship as the organization learns and evolves its AI strategy.

Technology Modernization

Companies modernizing legacy systems, migrating to cloud, or adopting new architectural patterns benefit from fractional CTO guidance on strategy and approach. The long-term engagement allows for phased implementation and course correction.

Security and Compliance

Organizations preparing for SOC 2 or ISO 27001 audits benefit from fractional CTO involvement in architecture reviews, security strategy, and compliance roadmapping. As mentioned in Padiso's focus on SOC 2 / ISO 27001 security audits, fractional engagement allows for ongoing security mentorship and governance.

Lighter-Touch Advisory

Some organizations need only occasional guidance—perhaps monthly office hours, quarterly strategy reviews, or ad-hoc technical mentoring. Fractional CTO Office Hours: Lighter Engagement Model describes how fractional CTOs can serve in this lighter capacity.

Use Cases: When to Choose Interim

Interim CTO engagements are ideal for:

Crisis Stabilization

When engineering is in chaos—missed deadlines, high turnover, failed projects, or departing CTO—an interim CTO brings external authority and fresh perspective to stabilize operations. The interim model works because the organization knows it's temporary and can tolerate directive leadership. When time-bound delivery or crisis response is required, a fractional vs interim CTO analysis will often recommend interim leadership.

Leadership Transitions

When a CTO departs and you need coverage while recruiting a permanent replacement, an interim CTO ensures continuity and prevents leadership vacuum. The interim leader can also participate in recruiting and onboarding the permanent CTO.

Major Platform Launches

When launching a new platform, migrating to a new architecture, or executing a major technical initiative with a tight deadline, an interim CTO can lead the effort with full-time focus and accountability. Once the launch is complete, the organization can transition to fractional advisory or permanent hire.

Acquisition and Integration

During M&A activity, an interim CTO can lead technology integration, rationalize systems, and establish new technical standards. The temporary nature of the role allows for decisive action without long-term commitment.

Board-Mandated Change

When a board or investor mandates significant technology changes, an interim CTO can implement those changes with authority and urgency. The interim leader can make tough decisions (e.g., sunsetting legacy systems, restructuring teams) that internal leaders might struggle with.

Government and Regulated Environments

Government agencies and highly regulated organizations often use interim CTOs to lead specific initiatives (e.g., modernization programs, security upgrades, compliance projects) with defined timelines and deliverables. As relevant to government modernization efforts, interim CTOs bring specialized expertise and can move quickly within bureaucratic constraints.

Hybrid and Blended Approaches

Many organizations use a hybrid model that combines fractional and interim elements. Hybrid strategies let you test fractional vs interim CTO combinations without committing to one model exclusively.

Fractional-to-Interim Transition:

An organization might start with fractional CTO guidance (e.g., 20 hours/week for 3 months) to assess the situation and develop a plan. If a crisis emerges, the engagement can shift to interim (e.g., 40 hours/week for 6 months) to execute the plan, then revert to fractional for ongoing guidance.

Interim-to-Fractional Transition:

An interim CTO might stabilize a crisis and then transition to fractional advisory (e.g., 10 hours/week) to mentor the permanent team and ensure sustainability of changes.

Parallel Fractional and Interim:

Some organizations engage a fractional CTO for ongoing strategy while bringing in an interim CTO for a specific project or crisis. The two work in parallel, with the interim leader handling the bounded problem and the fractional leader providing strategic oversight.

As discussed in Fractional CTO Engagement Models 2026 Buyers Guide, modern organizations increasingly use blended approaches to optimize for flexibility and cost-effectiveness.

Key Comparison: Side-by-Side Feature Matrix

To help clarify the differences, here's a detailed comparison:

Factor Fractional CTO Interim CTO Duration 6 months–indefinite 3–12 months (bounded) Time Commitment 10–40 hours/week (part-time) 40–60+ hours/week (full-time) Cost Model Monthly retainer ($5K–$20K+) or hourly Daily/weekly rate ($3K–$10K+/day) Total Investment Spread over long term Front-loaded, finite Strategic Focus Long-term capability building Rapid execution on bounded problem Hands-On Involvement Selective (60% strategy, 40% execution) Intensive (hands-on across all domains) Scope Well-defined, strategic Broad, operational, mission-driven Team Fit Requires capable internal team Works in crisis or leadership vacuum Decision-Making Collaborative, mentoring-focused Directive, authority-based Transition Gradual, planned Structured, documented Ideal For Scaling, modernization, advisory Crisis, launches, transitions Risk Scope creep, unclear ROI Incomplete transition, dependency

Pros and Cons: Fractional CTO

Pros:

• Cost-effective for organizations that can't justify full-time hire

• Flexibility to adjust hours and scope as needs evolve

• Cross-industry insights from fractional CTO's other engagements

• Long-term relationship builds institutional knowledge and mentorship

• Lower risk than permanent hire (easier to adjust or end)

• Equity alignment available for early-stage companies

• Sustainability through capability building and team development

Cons:

• Limited availability (part-time means less immediate responsiveness)

• Less operational ownership (requires strong internal leadership)

• Potential scope creep without clear boundaries

• Dependency risk (what happens if fractional CTO leaves?)

• Slower crisis response (not available full-time)

• Cumulative cost can be high over 24+ months

• Requires clear internal structure to avoid confusion about authority

Pros and Cons: Interim CTO

Pros:

• Full-time focus on immediate problem or project

• External authority to make tough decisions

• Rapid execution and crisis stabilization

• Defined timeline and cost (predictable investment)

• Fresh perspective on entrenched problems

• Intensive mentorship for internal team

• Clear transition plan from day one

Cons:

• Higher cost per unit of time than fractional

• Limited long-term strategy (focused on immediate problem)

• Potential institutional knowledge loss at end of engagement

• Disruption if internal team resists external leadership

• Transition risk if permanent leader isn't ready to take over

• Less sustainable if changes aren't embedded in culture

• May create dependency on external leadership

The Verdict: How to Choose

Here's a practical framework for deciding between fractional and interim CTO:

Choose Fractional CTO If:

1. Your organization is growing but stable (not in crisis)

2. You have a capable internal engineering team

3. You need strategic guidance and mentorship over time

4. You want to build sustainable technical practices

5. You're scaling to $10M–$100M+ revenue range

6. You need flexibility to adjust engagement as you grow

7. You're embedding AI, analytics, or modernizing technology

8. You want to mentor your VP Engineering or internal leaders

Choose Interim CTO If:

1. Your organization is in crisis or facing urgent technical challenge

2. You need full-time, intensive leadership for a bounded problem

3. You're launching a major platform or initiative with tight deadline

4. You're transitioning between CTOs or leaders

5. You need external authority to implement difficult changes

6. You have a clear end-state or success criteria

7. You're going through M&A or major organizational change

8. You need rapid execution over long-term strategy

Consider Hybrid/Blended If:

1. You need both strategic guidance and tactical execution

2. You want to start with fractional assessment, then shift to interim if needed

3. You're planning a multi-phase transformation (fractional for strategy, interim for execution)

4. You want fractional oversight with interim project leadership

As detailed in Fractional CTO vs Tech Advisor vs Head of Engineering, the right choice depends on your specific needs, team maturity, and organizational stage.

Preparing Your Organization for Either Model

Regardless of which model you choose, preparation is essential for success. Before any retained engagement, run a checklist comparing the fractional vs interim CTO expectations against your operating rhythm.

For Fractional CTO Engagement:

1. Define clear scope using a Fractional CTO Scope Document to prevent scope creep

2. Establish governance (decision-making authority, meeting cadence, communication channels)

3. Identify internal champion who owns day-to-day execution

4. Set 90-day milestones (as outlined in The Fractional CTO Engagement Model: How to Structure the First 90 Days)

5. Prepare your team for external leadership and mentorship

6. Align on success metrics and how you'll measure ROI

For Interim CTO Engagement:

1. Define mission statement and success criteria clearly

2. Establish end-state (when does the engagement end? what does success look like?)

3. Prepare for change (internal team may resist external leadership)

4. Plan for transition from day one (who takes over when interim leader departs?)

5. Document decisions and rationale for continuity

6. Allocate time for knowledge transfer in final 30 days

7. Identify permanent leadership (hire, promote, or shift to fractional)

Real-World Considerations for Enterprise and Government

For enterprise and government organizations, the fractional vs interim choice has additional nuances.

Enterprise Considerations:

Large enterprises often use fractional CTOs for strategic advisory on technology modernization, AI integration, and cloud migration. The fractional model allows enterprises to tap specialized expertise without full-time commitment. Fractional CTOs can also provide governance and security oversight aligned with SOC 2 and ISO 27001 requirements.

Enterprises use interim CTOs for crisis stabilization, major platform launches, or leadership transitions. The interim model is particularly valuable during acquisitions or when implementing board-mandated technology changes.

Government Considerations:

Government agencies increasingly use interim CTOs for modernization initiatives with defined timelines and deliverables. The interim model aligns well with government procurement cycles and project-based funding.

Fractional CTOs are valuable for ongoing security and compliance advisory, particularly for SOC 2 and ISO 27001 audits. Fractional engagement also supports government agencies in building sustainable engineering practices and mentoring internal teams.

As relevant to government technology modernization, both models offer flexibility and cost-effectiveness compared to permanent hires.

Common Pitfalls and How to Avoid Them

Fractional CTO Pitfalls:

• Unclear scope leading to scope creep and misaligned expectations

• Insufficient internal leadership leaving no one to execute fractional guidance

• Treating fractional CTO as full-time replacement (they're not)

• Lack of decision-making authority limiting fractional CTO's effectiveness

• Not measuring progress or defining success criteria

Interim CTO Pitfalls:

• No clear end-state or success criteria (engagement drifts)

• Inadequate transition planning (knowledge and decisions don't transfer)

• Internal team resistance to external leadership

• Over-reliance on interim leader without building internal capability

• Hiring permanent CTO without interim input (new leader doesn't understand context)

As discussed in When Fractional CTO Engagements Fail: How to Fix Them, clarity, governance, and transition planning are essential to success.

Questions to Ask Before Committing

Before engaging either a fractional or interim CTO, ask these critical questions:

For Fractional CTO:

1. What is the expected duration, and how will we know when to transition or end the engagement?

2. How many hours per week can the fractional CTO commit, and how flexible is that?

3. What decisions does the fractional CTO have authority to make unilaterally?

4. How will we measure success and ROI?

5. What happens if the fractional CTO becomes unavailable?

6. How will we handle scope creep or changing needs?

7. What is the process for onboarding and first 30 days? (Reference Fractional CTO Onboarding: First 30 Days)

For Interim CTO:

1. What is the specific mission and success criteria?

2. What is the expected duration and end-state?

3. How will the interim CTO transition their work to permanent leadership?

4. What authority does the interim CTO have to make decisions and implement changes?

5. Who is responsible for documentation and knowledge transfer?

6. How will we identify and prepare permanent leadership to take over?

7. What is the communication plan for the organization during the interim period?

As outlined in What to Ask Fractional CTO Before Signing Retainer, asking the right questions upfront prevents misalignment and ensures successful engagement.

Conclusion: Making the Right Choice for Your Organization

The fractional vs interim CTO decision is not binary—it's contextual. The right choice depends on your organization's stage, challenges, team maturity, and strategic priorities. Ultimately, a pragmatic fractional vs interim CTO decision balances urgency, budget, and the ability of your team to absorb change.

Fractional CTOs are ideal for organizations that need consistent, long-term strategic guidance from experienced technical leadership. They're cost-effective, flexible, and build sustainable capability. Fractional engagement works best when your organization is stable but growing, and you have internal leadership to execute on guidance.

Interim CTOs are ideal for organizations facing urgent, bounded challenges that require full-time, intensive leadership. They're effective for crisis stabilization, major launches, and leadership transitions. Interim engagement works best when you have a clear end-state and a plan for permanent leadership transition.

Many organizations use both models at different times or in parallel, depending on their evolving needs. The key is clarity about what you need, clear governance and scope, and intentional transition planning.

Padiso specializes in both fractional and interim CTO engagements, with deep expertise in AI-native development, autonomous agents, embedded analytics, and security audits (SOC 2 / ISO 27001). Whether you need ongoing strategic advisory or intensive crisis leadership, Padiso can help you evaluate which model fits your organization and deliver results.

Ready to explore fractional or interim CTO options for your organization? Contact Padiso to discuss your needs and find the right leadership model for your technology challenges.

As you evaluate your options, also consider reading When to Hire Fractional CTO vs Full Time CTO and CTO as a Service vs Full Time CTO: Making the Right Choice for Your Business for additional perspective on technology leadership options. Additionally, Fractional CTO vs Interim CTO: Which Do You Need in the US provides independent industry perspective on these models.

For organizations exploring whether a fractional CTO is right for their size, When Is a Business Too Small or Too Big for a Fractional CTO offers practical guidance on fit and stage. And if you're building an engineering team, Building Engineering Team Fractional CTO details how fractional leadership accelerates team development.

The choice between fractional and interim CTO is ultimately about matching your organization's needs with the right leadership model. With clarity, preparation, and the right partner, either model can drive significant value and accelerate your technology transformation.

For enterprises and government agencies, the fractional CTO engagement is particularly valuable during periods of digital transformation, AI integration, or when you need specialized expertise in areas like embedded analytics, autonomous agents, or security compliance. Organizations like yours often face the challenge of finding senior technical leadership that can move quickly while maintaining compliance standards such as SOC 2 and ISO 27001. The fractional model allows you to access this expertise without the long-term commitment or the complexity of building an entire C-suite.

Understanding when to hire a fractional CTO versus a full-time CTO is essential before you begin your search. Many enterprises discover that a fractional engagement during a specific transformation initiative or technology buildout phase delivers faster results and lower risk than hiring a permanent executive. The key is recognizing that fractional CTOs excel in outcomes-driven, time-bound engagements where you need strategic direction combined with hands-on delivery capability.

Step 1: Define Your Business Outcomes and Technical Needs

Photo by Christina @ wocintechchat.com M on Unsplash

The first and most critical step in hiring a fractional CTO is crystallizing what you actually need. This isn't about job descriptions—it's about defining the business outcomes you're trying to achieve. Are you building an AI-native product? Do you need to modernize legacy systems? Are you preparing for a security audit? Do you need to scale your engineering team? Your answer determines the type of fractional CTO expertise you should pursue.

Start by documenting your current state: What technology challenges are blocking your business? What are your revenue or operational goals for the next 12 months? What specific gaps exist in your current leadership or engineering capability? For enterprises, this often includes questions around digital transformation, cloud migration, AI integration, or security compliance. For government agencies, the focus might be on modernization, data governance, or meeting federal compliance requirements.

Next, identify the scope of work. Will your fractional CTO be responsible for strategy only, or do you need hands-on technical leadership and shipping capability? Do you need them to build and mentor an engineering team? Will they be responsible for vendor selection, architecture decisions, or managing external contractors? The scope directly influences the type of candidate you hire and the engagement structure you establish.

Document your timeline and constraints. How long do you anticipate needing this engagement? Is this a 90-day intensive push, or a 12-month transformation? Do you have budget constraints? Are there compliance or security requirements that will shape the engagement? Understanding engagement models and how to structure the first 90 days will help you communicate your needs clearly to potential candidates.

Create a simple one-page outcomes document. Include your top three business objectives, the technical initiatives required to achieve them, the current gaps in your team or capability, and your timeline. This document becomes your north star throughout the hiring process and ensures every candidate understands what success looks like.

Step 2: Assess Your Organization's Readiness

Photo by James Harrison on Unsplash

Before you hire a fractional CTO, you need to honestly assess whether your organization is ready to work with one effectively. A fractional CTO is most effective when there's clear executive sponsorship, defined decision-making authority, and a willingness to move quickly. If your organization is still debating whether to pursue digital transformation or lacks alignment on technical priorities, a fractional CTO will struggle to deliver impact.

Evaluate your current engineering team and structure. Do you have an existing team that the fractional CTO will lead, mentor, and scale? Or are you asking them to build from scratch? Understanding how to build an engineering team with a fractional CTO will help you determine the right profile. If you're starting from zero, you need a fractional CTO with strong hiring and team-building experience. If you have a team in place, you need someone skilled at mentorship, architecture, and scaling.

Assess your budget and commitment level. Fractional CTOs typically range from $8,000 to $25,000+ per month depending on experience, engagement model, and geography. Some work on retainers, others on day rates or equity arrangements. Understanding fractional CTO economics—hours, retainers, and equity will help you set realistic expectations. Enterprises often underestimate the commitment required. A fractional CTO needs access to your key stakeholders, decision-making authority, and the ability to move quickly without bureaucratic delays.

Review your governance and compliance requirements. If you're a regulated organization or government contractor, you need a fractional CTO with deep experience in compliance frameworks. Ask yourself: Do we need SOC 2 certification? ISO 27001? Federal compliance (FISMA, FedRAMP)? A fractional CTO with hands-on audit and compliance experience is invaluable here. Organizations often discover that compliance expertise prevents costly mistakes and accelerates security certifications.

Finally, determine the level of hands-on involvement you need from your executive team. A fractional CTO requires regular access to your CEO, CIO, or board. If your leadership team is unavailable or unable to make quick decisions, the engagement will stall. Ensure that whoever is sponsoring this hire understands the time commitment and decision-making authority required.

Step 3: Source Qualified Fractional CTO Candidates

Photo by Christina @ wocintechchat.com M on Unsplash

Once you've defined your needs and assessed your readiness, it's time to source candidates. The fractional CTO market has evolved significantly, and there are now multiple channels to find qualified talent. The key is using a combination of approaches to build a strong candidate pipeline.

Network and Referrals: Your best source of fractional CTO candidates is often your own network. Reach out to board members, investors, advisors, and peers in your industry. Ask: "Who is the best fractional CTO you've worked with or know?" Personal referrals come with built-in credibility and often lead to faster, higher-quality hires. For enterprises and government agencies, this network-based approach is particularly effective because fractional CTOs at the senior level often work through trusted relationships.

Specialized Platforms and Agencies: Platforms like Upwork, Toptal, Gun.io, and specialized fractional CTO networks have emerged to connect companies with experienced leaders. However, enterprise-grade platforms tend to produce better results than general freelance marketplaces. Look for platforms that specialize in C-level fractional roles and have vetting processes in place. When evaluating candidates on these platforms, focus on case studies, references, and specific experience with your industry or technology stack.

Executive Search Firms: For enterprises and government agencies, engaging a retained executive search firm that specializes in fractional or interim CTO placements can be worthwhile. These firms have deep networks, conduct thorough vetting, and often provide guarantees. The cost is higher (typically 20-30% of first-year fees), but for critical hires, the investment often pays off.

Venture Studios and Consulting Firms: If you're looking for a fractional CTO with hands-on delivery capability and access to a broader team, consider delivery-focused venture studios like Padiso that combine fractional leadership with co-build and execution capability. These firms bring not just the CTO but also access to engineers, architects, and specialists who can accelerate your initiatives. This is particularly valuable for government and enterprise clients who need compliance expertise, AI integration, or rapid shipping of complex systems.

Industry Events and Communities: Attend technology conferences, government contractor forums, and industry meetups where senior technologists gather. Many fractional CTOs are active in communities like YCombinator, Founders, or government technology groups. Building relationships in these spaces often yields qualified candidates.

As you source candidates, create a simple scorecard to evaluate each prospect. Include criteria like: relevant industry experience, track record with your technology stack, experience with your compliance requirements (SOC 2, ISO 27001, etc.), team leadership experience, and availability. This scorecard helps you compare candidates objectively and avoid hiring bias.

Step 4: Vet Candidates Thoroughly

Vetting a fractional CTO is different from hiring a full-time executive. You need to move quickly, but you also need to validate that the candidate can deliver on your specific outcomes. A thorough vetting process typically takes 2-4 weeks and includes multiple stages.

Initial Screening Call: Start with a 30-minute screening call focused on your outcomes and their relevant experience. Ask: "Tell me about a similar engagement you've led. What were the business outcomes? What was the technical approach? What challenges did you encounter?" Listen for specificity and evidence of hands-on delivery. Red flags include vague answers, a focus on process over outcomes, or lack of relevant experience.

Detailed Technical Discussion: Conduct a 60-minute technical discussion where you dive deep into your specific challenges. If you're building autonomous agents, ask about their experience with LLMs, prompt engineering, and deployment. If you need embedded analytics, ask about their hands-on experience with Apache Superset and ClickHouse. If compliance is critical, ask them to walk you through a SOC 2 audit they've led. A strong fractional CTO should be able to discuss technical details confidently and ask intelligent questions about your architecture and constraints.

Reference Checks: Always conduct reference checks with at least three previous clients. Ask specific questions: "What were the agreed-upon outcomes? Did this CTO deliver on them? How was their communication and responsiveness? Would you hire them again?" For enterprise and government clients, ask specifically about compliance experience, security practices, and how they handled complex stakeholder management.

Case Study or Work Sample: Ask the candidate to walk you through a specific case study or project they've led. Request details on the business problem, their approach, the team structure, the timeline, and the outcomes. If possible, ask for metrics: Did they reduce deployment time? Improve security posture? Accelerate revenue? A strong candidate should have concrete examples.

Compliance and Security Verification: For regulated organizations, verify that the candidate has the certifications and experience you need. If you require SOC 2 compliance, ask about their audit experience. If you need ISO 27001, ask about their security practices. For government contractors, verify their security clearance eligibility or prior government experience. This verification step is often overlooked but is critical for enterprise and government clients.

Trial or Discovery Engagement: Before committing to a long-term retainer, consider running a paid trial or discovery engagement. This might be a 1-2 week engagement focused on a specific deliverable: an architecture review, a security assessment, or a technology roadmap. A trial engagement costs $5,000-$15,000 but provides invaluable insight into how the candidate works, communicates, and delivers. It's one of the best ways to validate fit before committing to a larger engagement.

Step 5: Define the Scope and Engagement Structure

Once you've selected your fractional CTO, the next critical step is defining the scope and engagement structure clearly. Ambiguity here is the #1 cause of fractional CTO engagement failures. You need a detailed scope document that outlines expectations, deliverables, timelines, and success metrics.

Create a Scope Document: Your scope document should include: (1) Business outcomes and success metrics, (2) Specific responsibilities and areas of authority, (3) Time commitment and availability expectations, (4) Key deliverables and timeline, (5) Team structure and who reports to the fractional CTO, (6) Decision-making authority and escalation paths, (7) Compliance and security requirements, (8) Communication cadence and stakeholder management. Padiso provides a fractional CTO scope document template that you can adapt to your needs. This template ensures you cover all critical elements and reduce misalignment.

Establish the Engagement Model: Decide whether you're using a retainer model (fixed hours per week), a day-rate model (pay per day of work), or a hybrid model. For enterprises, retainers typically work better because they provide predictability and allow for ongoing strategic engagement. Most fractional CTOs charge between $8,000-$25,000+ per month for a part-time retainer, depending on experience and scope. Some also negotiate equity stakes in your company, particularly for startups or high-growth ventures.

Define the First 90 Days: Create a detailed 90-day plan that breaks down what you expect to accomplish in each phase. Understanding how to structure the first 90 days is critical. Typically, the first 30 days focus on assessment and relationship building, the next 30 days on strategy and planning, and the final 30 days on execution and team building. This structure provides clarity and allows you to evaluate whether the engagement is working before committing to a longer term.

Set Clear Success Metrics: Define what success looks like. If you're modernizing infrastructure, success might be "migrate 80% of workloads to cloud by Q2." If you're building an AI capability, success might be "deploy first autonomous agent to production by end of Q1." If you're pursuing compliance, success might be "achieve SOC 2 Type II certification by Q3." These metrics should be specific, measurable, and tied to business outcomes.

Establish Communication Norms: Define how often you'll communicate, who participates in what meetings, and how decisions get made. Most fractional CTOs work best with weekly strategy sessions, daily standups with the engineering team, and monthly business reviews with leadership. Establish clear escalation paths for critical decisions.

Step 6: Onboard Your Fractional CTO Effectively

The first 30 days of your fractional CTO engagement are critical. Poor onboarding leads to wasted time, misalignment, and failed engagements. A structured onboarding process accelerates time-to-value and sets the tone for the entire engagement.

Week One Priorities: During the first week, your fractional CTO should focus on understanding your business, meeting key stakeholders, and assessing your current technology landscape. This includes meeting with your CEO or executive sponsor, reviewing your product and business model, understanding your go-to-market strategy, assessing your engineering team and current technology stack, and identifying immediate risks or blockers. Understanding what a fractional CTO does in week one will help you prepare your team and provide the right access and information.

Access and Credentials: Ensure your fractional CTO has immediate access to all necessary systems: GitHub repositories, cloud infrastructure, security tools, compliance documentation, financial data, and customer feedback. Delays in access slow down the assessment phase significantly. For government and regulated organizations, ensure they understand your security protocols and get any necessary clearances or background checks completed.

Team Introductions and Stakeholder Mapping: Schedule meetings with your engineering team, product leadership, operations, and any external partners or vendors. Your fractional CTO needs to understand the team dynamics, current capabilities, and political landscape. This stakeholder mapping is particularly important in large enterprises where alignment across multiple departments is critical.

Assessment Phase: During the first 2-3 weeks, your fractional CTO should conduct a thorough assessment of your technology, team, processes, and compliance posture. This might include code reviews, architecture assessments, security audits, team capability assessments, and process reviews. The assessment should identify gaps, risks, and opportunities. Understanding the fractional CTO onboarding process for the first 30 days will help you prepare your team for this assessment.

Initial Recommendations and 90-Day Plan: By the end of week three, your fractional CTO should present initial findings and recommendations. This includes a prioritized list of technical initiatives, team changes, process improvements, and compliance actions. Together, you'll refine this into your 90-day plan with specific deliverables and milestones.

Establish Rhythm and Cadence: Lock in your regular meetings: weekly 1-on-1s with your CEO or executive sponsor, weekly team standups, monthly business reviews, and quarterly strategy sessions. This cadence keeps everyone aligned and creates accountability.

Step 7: Monitor Progress and Adjust as Needed

Once your fractional CTO is engaged and working, you need a system to monitor progress, identify issues early, and adjust as needed. Regular check-ins and transparency are critical.

Weekly Check-Ins: Have a 30-minute weekly check-in with your fractional CTO focused on: What was accomplished this week? What are the blockers? What's the priority for next week? Are we on track to meet our 90-day outcomes? These check-ins surface issues early and keep everyone aligned.

Monthly Business Reviews: Conduct a monthly business review where your fractional CTO presents progress against your agreed-upon outcomes. Include your CEO, CFO, and any other key stakeholders. Review metrics, celebrate wins, identify challenges, and adjust the plan if needed. This transparency builds confidence and ensures alignment.

Red Flags and Course Correction: Watch for red flags that indicate the engagement isn't working: the fractional CTO isn't available when promised, they're not engaging with your team, they're not making progress on agreed-upon deliverables, or there's misalignment on priorities. If you notice these issues, address them immediately. Have a direct conversation about expectations and whether adjustments are needed. Understanding when fractional CTO engagements fail and how to fix them will help you diagnose and address problems before they derail the engagement.

Quarterly Evaluations: Every 90 days, conduct a comprehensive evaluation of the engagement. Did you achieve your agreed-upon outcomes? Is the fractional CTO delivering value? Are there new priorities that have emerged? Should you extend the engagement, adjust the scope, or make a change? This evaluation point is critical for making intentional decisions about the future of the engagement.

Step 8: Plan for Transition and Long-Term Success

As your fractional CTO engagement progresses, you need to think about the long-term arc. Will this be a one-time engagement, or an ongoing relationship? If you're building a full-time engineering organization, how does the fractional CTO transition to a permanent role or to an advisory capacity?

Build Institutional Knowledge: Ensure that your fractional CTO documents their decisions, architecture choices, and strategic recommendations. This creates institutional knowledge that survives beyond the engagement. Create architecture decision records, process documentation, and strategy playbooks that your team can reference.

Develop Your Team: A great fractional CTO should be mentoring and developing your team. By the end of the engagement, your engineering team should have grown in capability and independence. If the fractional CTO has been effective, your team should be able to execute on the strategy they've outlined with less hands-on involvement.

Plan for Transition: If your engagement has a defined end date, plan the transition 4-6 weeks before completion. This includes: documenting all decisions and recommendations, training your team on ongoing execution, establishing success metrics for the next phase, and deciding on any ongoing advisory or fractional engagement. Some organizations transition their fractional CTO to a part-time advisory role or quarterly check-in cadence.

Consider Ongoing Engagement: For many enterprises, the fractional CTO model transitions to an ongoing relationship. Rather than a full-time hire, you maintain a fractional engagement (5-10 hours per week) for ongoing strategic guidance, vendor selection, architecture decisions, and mentorship. This model provides continuity and access to senior expertise without the overhead of a full-time executive.

Understanding when to transition from fractional to full-time CTO will help you make the right decision for your organization's stage and needs.

Key Considerations for Enterprise and Government Organizations

If you're an enterprise or government agency, there are specific considerations that apply to your fractional CTO hiring process.

Compliance and Security Expertise: Your fractional CTO must have hands-on experience with your compliance requirements. If you need SOC 2 certification, they should have led multiple SOC 2 audits. If you need ISO 27001, they should understand the framework deeply. For government contractors, they should understand federal compliance requirements (FISMA, FedRAMP, etc.). This expertise prevents costly mistakes and accelerates compliance timelines.

Vendor and Contractor Management: Enterprise and government organizations often work with multiple vendors and contractors. Your fractional CTO should have experience managing these relationships, evaluating vendors, negotiating contracts, and ensuring compliance across the vendor ecosystem.

Stakeholder Management: Enterprise organizations have complex stakeholder landscapes. Your fractional CTO needs to be skilled at managing relationships across multiple departments, board members, and external partners. They should be comfortable presenting to executive leadership and government officials.

Data Governance and AI Ethics: For organizations implementing AI and analytics, your fractional CTO should have expertise in data governance, responsible AI practices, and embedded analytics platforms like Apache Superset and ClickHouse. This expertise is increasingly critical for regulated organizations.

Multi-Team Coordination: Enterprise organizations often have multiple engineering teams and geographic locations. Your fractional CTO should have experience coordinating across these teams, establishing shared standards, and scaling processes.

Prerequisites Before You Start the Hiring Process

Before you begin hiring a fractional CTO, ensure you have these prerequisites in place:

• Executive Alignment: Your CEO, board, and key stakeholders must be aligned on the need for a fractional CTO and committed to the engagement.

• Budget Approval: You need approved budget for the engagement, including contingency for extended scope or additional resources.

• Clear Outcomes: You must have defined business outcomes and success metrics for the engagement.

• Decision-Making Authority: Your fractional CTO needs clear decision-making authority and access to key stakeholders.

• Team Readiness: Your existing team (if any) should be prepared for the arrival of a fractional CTO and understand how they'll work together.

• Infrastructure Access: You need to be able to provide immediate access to systems, repositories, documentation, and stakeholders.

• Compliance Documentation: If you're a regulated organization, you should have your compliance requirements and existing audit results documented.

Pro Tips for Success

Run a Paid Trial First: Before committing to a long-term retainer, run a 1-2 week paid trial engagement. This allows you to evaluate fit, communication style, and delivery capability with minimal risk. Many organizations find this $5,000-$15,000 investment saves them from expensive hiring mistakes.

Check References Thoroughly: Don't just ask generic questions. Ask previous clients about specific outcomes, communication style, and whether they'd hire again. For enterprise and government clients, ask about compliance and security expertise.

Define Success Metrics Upfront: Ambiguity about success is the #1 cause of failed fractional CTO engagements. Define specific, measurable outcomes before you hire. Understanding what questions to ask a fractional CTO before signing a retainer will help you ensure alignment.

Look for Hands-On Delivery: The best fractional CTOs aren't just strategists—they ship code, lead architecture decisions, and roll up their sleeves. Look for candidates with recent hands-on experience, not just consulting background.

Consider Venture Studio Models: For complex initiatives like AI integration or compliance transformation, consider engaging a delivery-focused venture studio that combines fractional CTO leadership with access to engineers and specialists. This model accelerates execution and reduces risk for enterprise digital transformation initiatives.

Invest in Onboarding: Don't skip the onboarding process. Spend time upfront ensuring your fractional CTO understands your business, team, and constraints. This investment pays dividends in faster time-to-value and stronger relationships.

Maintain Regular Communication: Weekly check-ins, monthly business reviews, and transparent reporting keep the engagement on track. Don't go dark for months and expect great outcomes.

Common Mistakes to Avoid

Hiring Without Clear Outcomes: The #1 mistake is hiring a fractional CTO without defining what you actually need. Vague job descriptions lead to misaligned expectations and failed engagements.

Underestimating the Commitment Required: Fractional CTOs need access to leadership, quick decision-making, and active engagement. If your organization can't provide this, the engagement will stall.

Skipping the Vetting Process: Don't hire based on a resume or one conversation. Conduct thorough reference checks, technical discussions, and ideally a trial engagement.

Lack of Scope Definition: Without a detailed scope document, both you and the fractional CTO will have different expectations. Invest time upfront in a clear scope.

Not Planning for Transition: Think about the long-term arc from day one. How will this engagement transition to ongoing work or a permanent hire? Planning this upfront prevents surprises later.

Ignoring Red Flags: If the fractional CTO isn't available, isn't engaging with your team, or isn't making progress, address it immediately. Don't hope it improves.

Summary and Key Takeaways

Hiring a fractional CTO is a significant decision that can accelerate your technology transformation and business outcomes. The key to success is following a structured process: define your outcomes, assess your readiness, source qualified candidates, vet thoroughly, define scope clearly, onboard effectively, monitor progress, and plan for the long term.

The fractional CTO model is particularly valuable for enterprises and government agencies pursuing digital transformation, AI integration, or compliance initiatives. By following this step-by-step guide, you'll avoid common pitfalls and set yourself up for a successful engagement that delivers measurable business outcomes.

Remember: the best fractional CTOs combine strategic thinking with hands-on delivery capability. They're not just advisors—they ship outcomes. Look for candidates with proven track records, relevant expertise, strong communication skills, and a commitment to your success. And don't skip the trial engagement; it's one of the best ways to validate fit before committing to a long-term relationship.

If you're ready to explore fractional CTO options for your enterprise, Padiso specializes in fractional CTO, AI-native development, and program leadership for enterprise and government clients. We combine senior technical leadership with hands-on delivery capability to accelerate your technology transformation. Whether you need strategic guidance, hands-on execution, or a combination of both, we can help you navigate the fractional CTO hiring process and structure an engagement that drives results.

A CEO asked me this last month over coffee in Sydney.

Manufacturing business, around 60 staff, profitable, no CTO. He’d been quoted $180K by a systems integrator, $2,400 a month by a SaaS vendor, and had a very keen 26-year-old on his team volunteering to “just build it with Cursor.”

He wanted me to tell him which one to pick.

I told him he was asking the wrong question, which is a rude thing to say to someone who has just bought you a coffee. But he was. All three quotes were answers to a question he hadn’t defined yet, and the gap between those numbers — $2,400 a month versus $180K — wasn’t a pricing difference. It was three vendors guessing at three completely different scopes.

Here’s the framework I use, across PADISO’s client work and inside my own companies. It starts by throwing out the assumption underneath the question.

This Substack is reader-supported. To receive new posts and support my work, consider becoming a free or paid subscriber.

The old logic is inverted

For twenty years, the buy-versus-build decision ran on one dominant variable: construction cost. Building software was expensive and slow, so you built only what was strategically essential and bought everything else. That was correct advice. I gave it myself for most of my career.

That variable has collapsed.

Roughly 25% of the SearchFit codebase is written by agents — Claude Code and Codex, running against a spec I write and a review I do. Features that would have required three or four engineers now require me and an afternoon of supervision. I’m running three companies from Sydney with a technical team you could fit in a small lift.

So building is cheap now. Which means, counterintuitively, build is no longer the expensive option — and buy is no longer the safe one.

What hasn’t got cheaper is everything around the code:

• Integrating with the booking system that hasn’t been updated since 2019

• Cleaning the data in the CRM that four different sales managers have used differently

• Deciding what the thing should actually do

• Owning it when it breaks on a Tuesday

That’s where the money goes now. Every AI project I’ve seen fail — and I’ve been called in to rescue several — failed at integration, data quality, or ownership. Not one failed because the model wasn’t smart enough.

So stop asking “what’s cheapest to build.” Ask “who owns this in eighteen months, and what happens the first time it’s wrong?”

Question one: is it a differentiator or a utility?

The cleanest cut in the whole decision.

Utilities are the things every business in your category needs and none of them win on. Transcription. Email drafting. Meeting notes. Document search. Support ticket deflection. Basic forecasting.

Buy these. Always. Do not let anyone build them for you, in-house or otherwise. There are funded companies with fifty engineers competing to make these cheaper and better every quarter, and you will never out-run them. If someone quotes you $80K to build an internal meeting-notes tool, that’s not an AI project, that’s a hobby with an invoice attached.

Differentiators are the things that encode how your business specifically makes money. The pricing logic your ops director keeps in her head. The way you triage inbound leads because you know which postcodes convert. The compliance workflow that’s specific to your licence. The quoting process that takes your estimator three days.

Nobody sells this. It doesn’t exist as a product, because the market for it is exactly one company. If you try to buy it, you’ll buy a generic platform and spend nine months and a change-request budget bending it into a shape it was never designed to hold.

Most executives get this backwards. They buy a big platform to handle the differentiated work and then build a scrappy internal tool for a utility, because the platform vendor had better sales collateral.

Question two: does it touch your mess?

This is the question that decides more outcomes than any other, and it never appears on a vendor comparison matrix.

Every real business runs on a substrate of legacy systems, half-documented processes, and data that’s technically wrong in ways everyone has quietly agreed to work around. At PADISO we wire agents into that reality — revenue tracking across booking platforms, self-updating Power BI dashboards, email pipelines, orchestration through N8N and custom agent architectures. The AI part is genuinely the easy part now. The hard part is that your “customer” table has three spellings of the same company name and a field called notes2.

If a proposed solution has to touch that mess, you cannot buy your way out of it. No vendor is going to reconcile your data model for a monthly subscription. They’ll give you an API and a Zapier connector and a smile.

If it doesn’t touch the mess — if it’s a standalone tool sitting at the edge of your operation — buying is almost always right.

Ask any vendor one question: “Show me exactly what happens when this reads from our systems and the data is wrong.” Their answer tells you whether they’ve deployed into a business like yours or only into slide decks.

Question three: who gets paged?

An AI system isn’t a purchase. It’s a dependency, and dependencies need owners.

Answer this before you sign anything:

• When the agent makes a wrong decision, who finds out — and how fast?

• When your CRM vendor changes an API in six months, who fixes it?

• When the person who understood the workflow leaves, what’s left behind?

Build in-house only if you have — or are willing to hire — someone who can hold that ownership. Not someone who can write code. Agents write the code. Someone who can specify clearly, evaluate whether the output is correct, and architect systems that don’t collapse under load. That’s a different profile from the one you’re used to hiring for, and it’s rarer than a good developer, not more common.

If you don’t have that person and you’re not ready to hire them, in-house build is how you acquire an unmaintained system with your logo on it.

Buy when the vendor owns the pager, and price the subscription as what it actually is: rent for not having to think about it.

Hire an agency when you need the capability faster than you can hire it, and you have a specific outcome in mind rather than a general desire to “do something with AI.”

The fourth option nobody quotes you for

Most businesses I work with don’t land on any of the three. They land on the combination, which is:

Buy the platform. Build the workflow. Hire someone to wire it together and then leave.

You buy the model access and the infrastructure — you are not training a foundation model, please do not let anyone tell you that you should. You build the thin, specific layer that encodes how your business works, because that layer is the whole point. And you bring in outside help for the twelve weeks it takes to get it into production, with a hard requirement that they hand you documentation, tests, and a runbook on the way out.

That last part is the bit to negotiate hard on, because the agency incentive runs directly against it.

How to buy an agency without getting burned

Since I run one, treat this as a confession rather than a sales pitch.

Buy outcomes, not hours. “Reduce quote turnaround from three days to four hours” is an outcome. “Two senior engineers for six months” is a staffing arrangement with extra steps, and it transfers all the risk to you.

Get IP assignment in writing. Not a licence. Assignment. If the workflow encodes how your business makes money, you own it — including prompts, agent definitions, and configuration, not just source code.

Demand a handover artefact. Documentation, tests, and a written runbook for what to do when it misbehaves, delivered as a milestone, not a favour at the end.

Ask what they run internally. Any agency selling AI transformation should be visibly running on it. If they can’t show you their own agents, their own automations, their own numbers, you’re buying a deck. We fund product bets at SearchFit and Capitaly off PADISO’s consulting revenue, and increasingly the consulting itself is delivered by agents — I’m using AI to build the AI consultancy that funds the AI products. That’s the standard I’d hold any agency to, including mine.

Start with one workflow. Anyone who wants to sell you an eighteen-month transformation programme before proving a single process in production is selling you optionality on their own revenue.

The ninety-day test

Before committing capital in any direction, run this:

1. Pick one workflow with a number attached to it — hours, error rate, turnaround time, cost per unit.

2. Measure the baseline for two weeks. If you can’t measure it, you’ve picked the wrong workflow, and you also can’t prove ROI later.

3. Ship something narrow into production in six weeks. Production, not a demo. A demo proves the model works. Production proves your business works.

4. Run it for six weeks with a human checking every output.

5. Then decide buy, build, or agency — with actual evidence about where the difficulty lives.

Ninety days and a contained budget buys you a real answer to a question that no vendor comparison, analyst report, or LinkedIn framework can give you: where in your specific business the friction actually is.

Almost every organisation is wrong about this before they test. They think the problem is the AI. The problem is nearly always the data, the integration, or the fact that nobody wrote down how the process really works.

The one-line version

If it’s a utility, buy it. If it’s how you make money, build it. If you need it faster than you can hire for it, bring in help — but own the output and take the pager back at the end.

And if you genuinely can’t tell which category something falls into, that’s not a procurement problem. That’s a strategy problem, and no amount of spend will fix it.

The company that spends $50K on the right workflow will beat the one that spends $500K on the wrong platform. Every time. I’ve watched it happen from both sides of the invoice.

I’m Kevin — CEO of PADISO and SearchFit, running three companies from Sydney with a two-person engineering team. I write about what the AI-native operating model actually takes, and what breaks. If this was useful, subscribe.