When Do You Need a Fractional CTO, and When Is the Job Smaller?

A fractional CTO, in the sense the question is usually asked, is a fractional chief technology officer: one senior technology person bought for part of a week or part of a month by a company that already has something running. The word here has nothing to do with owning a fraction of anything, the finance meaning is a different subject, and in crypto those same three letters stand for a community takeover, which is a different subject again.

Most owners of one working app and no engineers do not need one. Four situations change that answer: somebody is already writing code and nobody sets the direction, an outsider is about to examine the technology, a decision is coming that would be expensive to undo, or the person who has been the technical answer is leaving.

Each of the pages ranking for this question answers it with a list of signals: three inflection points on one, five patterns on another, then five situations, seven signs and five signs. Read the lists next to each other and what they have in common turns out to be the reader they are addressed to, who has engineers, or a board, or an executive who has just resigned. If your company is you and an application that works, most of those signals cannot fire at all, and the lists say nothing about the case you are actually in.

Here is the reading behind this page. Five of the pages Google ranks for this decision were opened in their own page source on 2 September 2026 and compared on one question, which is what each published signal takes for granted about the reader. Nobody was recruited, shortlisted or paid anything for it, no seller was approached, and none of the arrangements described below was bought or taken on anywhere in this work. Every company below is named in the sentence and left unlinked, because each one either sells this role, places the people who fill it, or sells advice to whoever is reading this. One owner’s account of their own uncertainty comes from a public post, carried anonymously and reworded rather than quoted.

What the ranked pages assume before they list the signals

Five pages carry most of this decision in the results, and none of them is linked here. TechCXO, a firm that supplies part-time executives, publishes three inflection points at www.techcxo.com/insights-when-to-hire-a-fractional-cto/, dated 12 February 2026. Fractionus, a marketplace, publishes five patterns at fractionus.com/blog/fractional-cto-what-they-do-when-you-need-one, dated 25 March 2026. KORE1, a staffing firm, publishes five situations at www.kore1.com/what-is-a-fractional-cto/, published 27 March 2026 and marked last updated 2 July 2026. Amazing CTO, a coaching practice, publishes seven signs drawn from the author’s own conversations with founders at www.amazingcto.com/signs-you-need-fractional-cto/, dated 12 January 2026. SelectWise, an advisory practice, publishes five signs at selectwise.io/blog/5-signs-sme-needs-fractional-cto, dated 9 May 2026. All five were read in their own page source on 2 September 2026.

None of the five is wrong. Each one is written from inside a business that sells this role to companies that already employ engineers, and the signals are accurate for those companies. The interesting part is what each signal needs to be true before you can even notice it.

Six of the eight need other people before they mean anything. KORE1’s first situation is written around a company with twelve engineers whose founder is still reviewing their work at midnight. Its second is written around a team that went from five engineers to twenty in a year. TechCXO’s piece is addressed throughout to a reader who has a product team and an engineering organisation to point somewhere.

Even the pattern written explicitly for a non-technical founder assumes staff. Fractionus describes founders with non-technical backgrounds finding themselves at the mercy of their engineering team or agency, which is a founder who is already paying somebody. Amazing CTO’s first sign is the closest any of the five comes to this page’s reader, a non-technical founder who paid a development shop and cannot tell whether what came back is any good, and the same post then states the division plainly: the reader does not need somebody to write the code, because the developers do that.

That leaves two signals that survive intact, one that survives in half, and five that describe a company you do not have. Two of those five come back in a smaller form once you stop reading them as facts about an organisation: the departing executive becomes one contractor who stops replying, and the founder making every technical call becomes a founder making them alone. Nobody on this search writes for the person who owns one working application, employs no developers, and has never had the code read by anybody, so the four situations below are what those signals look like from there.

Four situations where the missing thing really is technology leadership

One owner listed what they were unsure about before committing: whether it would hold up, whether it would carry more people, whether it would keep working, and whether the thing they had was a demonstration or a business. Four worries, and the first three are questions about software, which somebody reading and repairing it can settle. The fourth is a judgement about where the company is, and of the four it is the one that points at a person who owns decisions rather than at a piece of work.

Somebody is already writing code for you and nobody sets the direction. A contractor, a friend, an agency, one part-time developer you found last spring. They ask you what to build and you answer, because there is nobody else to ask, and half your answers are guesses about things you cannot evaluate. This is the one situation the ranked pages and this page agree on completely, and it is the situation their signals were written for, just at a smaller headcount. Where people look for somebody to fill that seat, what each channel screens for, and what the first call should cover is its own subject. So is the list of questions worth putting to a candidate before anybody signs anything, including the ones that reveal whether the person will ever open your code. If the person you are imagining would take a slice of the company instead of a fee, that is a different arrangement altogether, and whether you need one of those is answered on its own page.

Somebody outside is about to examine the technology and you will have to answer for it. An investor doing technical due diligence, a buyer, or a large customer sending a written security assessment to fill in. All three of the staffing and marketplace pages name this one, and it survives the translation unchanged, because the person asking does not care how many engineers you employ. What a reviewer actually looks for before an investment goes through is a separate answer, and so is what to do when a large customer’s assessment arrives and none of the questions were written with a small application in mind. What you need in the room is somebody who can answer for decisions that were made, which is a different purchase from somebody who can fix what those decisions broke.

A decision is coming that would be expensive to undo. Leaving the builder your app was made in, moving where the data lives, committing to a platform you will still be on in two years. KORE1 and Fractionus both name a large technology decision as a reason to buy senior judgement, and this is the signal that translates best of all, because a decision that is expensive to undo does not get cheaper when the company is small. It gets more expensive, because there is nobody to absorb the mistake. Two of the commonest versions have their own answers: the decision to leave the builder and repairing what exists against starting again are both worth reading before you buy anybody’s opinion about them, because one of them may turn out not to be a decision at all.

The person who has been the technical answer is leaving, and it is not you. The ranked pages write this one as a resigning executive with a team beneath them. For an owner with one app it is one contractor who has stopped replying, or one friend whose new job has swallowed their weekends. The gap is the same shape at both sizes: nobody left who knows why anything was done the way it was done. What to get back when the person who built it stops replying comes first, and it is a list of accesses and accounts rather than a hire. After that, putting one person in charge of the whole thing is a real option and it is not the same option as the one this page is about, because it buys somebody who works on the app rather than somebody who decides what happens to it.

Three situations where what is missing is one piece of work

Three more situations bring people to this question, and from the inside they feel identical to the four above. In each of them the missing thing has a finish, and hiring somebody to own the technology decisions would mean paying month after month for something that stops being true.

One of them is a single named thing that is wrong or absent, describable in one sentence. New accounts stop arriving after a change you did not make. A monthly summary that used to send has gone quiet. There is no way to refund a customer without editing the database by hand. Work that can be described that precisely can be bought that precisely, and no direction is missing, because you already know what you want to happen. Which items on a short list justify paying anybody, and which stay yours, gets decided item by item on another page, and the timing underneath it, the point at which paying a developer stops being premature, is settled on a third.

Harder to see is the one where the facts that would settle this decision are inside software that nobody has read. Look back at the table: every published signal is something you could observe from across the room, because every one of them is a fact about an organisation. Yours are not observable at all. Whether a decision expensive to undo is actually coming, whether what you have will carry more people, whether the thing that keeps breaking is one bug or a pattern, all of that lives in code that no human being has opened, including the person who wrote the prompts. What a paid reading of the code covers is bought from people who do it for a living, and one reading turns a decision you cannot make into either a short list of named jobs or a far better founded case for hiring somebody senior. Buying a single expert opinion for an hour or two is a different and cheaper purchase again, and the page about that one marks where it is strong and where it runs out.

The last of the three takes a sentence, because the answer to it lives elsewhere. If what you actually want is somebody who will be available when the app breaks, that is a question about a monthly arrangement rather than about technology leadership, and both what a month with a developer buys for one app you already run and what published monthly agreements actually contain are worked out on pages about that purchase.

Is the thing you are short of direction, or work?

Two questions settle it, and neither is about how big or how complicated the app is. Count the technology decisions ahead of you that outlive this month and would be expensive to undo. Then ask whether anybody would act on the direction once somebody sets it. If the honest answer to the second is nobody, the purchase is work.

The first question is a counting exercise and most people overestimate it. Renaming a plan, adding a second user role and choosing between two payment providers are three decisions with three different costs of reversal: the first is trivial, the second drags authorisation rules and existing records with it, and the third is the expensive one. If you can only name one such decision, and it is the one in front of you this month, one person’s judgement bought once will answer it. If you can name four, and two of them depend on the other two, that is a stream of decisions, and a stream is what a continuing arrangement is for.

The second question gets skipped more often than it gets asked, and it changes more answers than the first one does. Everything the five ranked pages describe is leadership exercised through other people. Fractionus states it directly in its own answer about existing staff: in most cases the existing engineering team continues in their roles and the fractional CTO steps in as the senior leader above them. TechCXO tells buyers the person needs access, authority and trust. All of that assumes somebody to have authority over. If there is nobody, the direction gets set and written down, and then either the founder carries it out or it sits there; a candidate who will also do part of the work is a different arrangement, and worth asking for by name.

If nobody is going to act on the direction, direction is not the thing you are short of.

That is why the two questions come in that order. A stream of expensive decisions with nobody to carry them out still leaves you doing the carrying, and you will be buying advice about a job you then have to hire somebody else to do.

What the sellers say the arrangement needs from your side

The published shape of this arrangement is not a secret, and it is worth reading before deciding, because most of what it asks for is not money.

It asks for a share of a week, repeatedly. Fractionus describes the work as part-time, “typically two to three days per week”, in the article text of its own page. KORE1 puts it at “Typically 10 to 20 hours per week”, flexing higher during a large piece of work. SelectWise, writing for small and mid-sized businesses, puts the usual commitment at two to eight days per month and says two to four days a month is enough for most of the businesses it writes for. Three sellers, three different units, and no agreement between them, which tells you the unit is negotiable and the number is not a norm.

The second thing it asks for is a length. KORE1’s own question-and-answer section states that “Six to 18 months is the most common range”, with some buyers using the arrangement as a bridge to a permanent hire and others keeping it for years. That is a long time to be paying for direction if the direction runs out after the first month.

Third, and easiest to miss because every page states it as a benefit, it asks for somebody to lead. The Fractionus answer named above puts the person above an existing team rather than in place of one. SelectWise, answering whether the role is needed when developers are already employed, draws the line at deciding what gets built rather than building it.

Last, it asks for standing inside the company. TechCXO’s own guidance tells the buyer not to treat the person as an outside consultant, and asks for full visibility of the leadership conversation rather than an arm’s length view of it.

Read together, what the arrangement asks you to supply is somebody for the direction to land on, a real say in what happens next, and enough months for either of those to matter. The fee is the easy part. Whether a candidate reads your software or only ever gives an opinion about it varies from person to person rather than from title to title, and that distinction is argued out in full elsewhere. So is the money: no figure appears anywhere on this page, and what providers publish for this arrangement is collected, dated and named on the page that does only that job. What the job itself covers, decision by decision, in a company that has somebody doing it, is a third page again.

Is a fractional CTO for a company the size of yours?

Size on these pages is counted in people rather than in applications. Only one of them publishes a size band, and it starts at ten employees, while another draws its ceiling at fifty engineers. One person with one working application sits below every published floor, which is a fact about the pages rather than a verdict on the company.

Searches for a fractional CTO for SMEs land on pages like SelectWise’s, which writes for small and mid-sized businesses and defines them as having ten to a hundred and fifty employees, with signs that read accordingly: subscriptions accumulating, developers saying everything takes months, a managed supplier nobody can evaluate. Every one of those needs staff or suppliers to exist. KORE1 marks the other end of the range, naming the point at which the part-time shape stops working: a technology team beyond fifty engineers, preparation for a public listing or large institutional fundraising, and technology becoming the company’s main competitive advantage.

Below the floor, the question changes rather than disappearing. It stops being how much of a technology executive to buy and becomes whether the decisions in front of you need somebody who owns them. That is what the test above is for. The permanent version of the same decision, with what a full-time technology hire actually costs and what the market pays, belongs on the page about hiring one outright, and what the role is in general terms, before any of the sizing, belongs on the page that defines it. Neither answer is repeated here.

What I am, in a page full of roles

It is none of the arrangements described above: not a fractional chief technology officer, not a part-time technology executive, not an advisory arrangement, not a team kept on by the month, and nobody is placed with anybody. If the test above came out as a stream of decisions with somebody to act on them, the purchase is a person and the pages named above are where that purchase gets made.

Common questions about when to hire a fractional CTO

Is a fractional CTO a thing, or a title people give themselves?

Both, which is why the shape matters more than the noun. It is a real arrangement with a real market, and the five pages read on 2 September 2026 publish concrete shapes for it: a number of days a week or a month, a usual length running into months, and a place in the company above somebody. Anybody using the title with none of that attached is selling something else, and the market sells the same arrangement under several other names as well.

Should I hire one if nothing is going wrong right now?

Almost certainly not, on the published evidence. Of the eight signals across the five ranked pages read on 2 September 2026, six need staff, a board or a departing executive before they can fire at all, and the two that survive for a one-app owner are both events rather than conditions: somebody outside asking technical questions, or a decision ahead that would be expensive to undo. A working app with no complaints and no such event in front of it is not a situation any of these pages describes.

Does a small business with one app need one?

Rarely, and the sizing on the published pages says so plainly. SelectWise writes for small and mid-sized businesses of ten to a hundred and fifty employees, and three of its five signs are about accumulated software subscriptions, developers who say everything takes months, and suppliers nobody can evaluate. One person with one application has none of those. The question worth asking instead is whether any decision in the next six months would be expensive to reverse.

How long do people usually keep the arrangement going?

KORE1, a staffing firm, states in the question-and-answer section of its page, published 27 March 2026 and marked last updated 2 July 2026, that “Six to 18 months is the most common range”, with some companies using the arrangement to bridge a search for a permanent hire and others keeping it for years. No other page in the set publishes a length. Treat it as one firm’s account of its own market rather than a standard, and ask what happens at the end before you agree to the beginning.

What is the difference between this and paying a developer by the month?

One buys decisions and one buys availability. A part-time technology leader decides what gets built, what gets replaced and what gets ignored, and on every page read here that judgement is exercised through other people who do the work. A monthly arrangement with a developer buys hours and a queue position, and somebody who opens the code themselves.

If the second one is what you want, what a month of a developer’s time covers for an app you already run has its own page, and the shapes those written monthly agreements take, unused hours included, are set out on another.

Can I make this decision without being able to read the code?

Partly. Every situation on this page that genuinely calls for somebody senior can be seen from outside the software: somebody is writing code with no direction, an outsider is about to examine the technology, a decision expensive to undo is coming, or the person who knew everything is going. Not being able to read the code does not hide any of those from you.

What it does hide is the other half of the answer, because whether the work in front of you is one job or an unbounded stream is a fact about the code. Paying somebody to read it and write up what they find settles that half at a price with a limit on it, and a single paid opinion, bought once by the hour, is the cheaper cousin of that and has its own page.

Who decides the technical direction if I do not hire anybody?

You do, by default, one decision at a time, usually at the moment somebody asks you a question you were not ready for. That works while the decisions are small and reversible, and it stops working when they are not. Rather than hiring in advance of that moment, write down the decisions you already know are coming in the next six months. If the list is short and each item is reversible, carry on. If two items on it would be expensive to undo and depend on each other, that is the moment the question in this page’s title becomes a real one.

Does it change anything if a generator wrote the code?

It changes the order rather than the answer. When a generator wrote the application, no human being has been through what it produced, the person who typed the prompts included, so the facts that would tell you which purchase you need stay locked in the software until somebody opens it. The reading comes before the hiring decision rather than after it.

What a part-time technology leader can settle for an application a generator wrote, and what has to wait until the code has been read, is worked out in detail on the page about that case.