What a Fractional CTO Does, and Who Writes the Code

The subject here is a fractional chief technology officer, meaning somebody senior who holds the technology decisions at a company with a live application for a couple of days a week instead of full time. Fractional in this phrase is not the finance sense, the one about owning a slice of a jet or a building, the three letters are not the takeover that crypto forums use them for, and none of this is the dictionary entry for the same job title at a company with two thousand staff.

You have an application. It works, people are using it, and most of it was produced by somebody else’s tool or somebody else’s contractor. Now you are deciding what sort of person to bring in, and you have met the phrase more than once. What you want to know is narrower and more practical than a definition: when the money starts moving, will this person be the one who opens the code, or will they tell you what ought to happen to it and expect somebody else to do the opening?

Nine pages across the result sets these questions return were opened on 2 September 2026 and read as raw page source, each checked for a single thing: what it says about who touches the code. Two of the nine turned a plain automated request away that day and answered a second request shaped the way a browser shapes one, down to the protocol version and the client name it announces, and what each of those two addresses actually returned is set out under the table. No fractional CTO was hired, interviewed, placed or paid for anything written here, and nothing was tested for it.

On the pages holding this search, most describe the role as direction, hiring and architecture and assume somebody else does the building; one says it is settled per engagement, and B. D. Emerson’s page, dated 25 August 2026, puts strategy and execution together. That is what these nine pages promise, and it is a read of the pages rather than a survey of the market. Where nobody is doing the building, that is the hole to fill first.

What a fractional CTO does, and the responsibilities each page publishes

Two searches carry this question. One is the plain activity search, and it returns nine organic results: two publishers who write definitions for a living, five sellers of the arrangement, one community thread and one post on a professional network. The other is the blunt version of the same question, whether people in this role write code, and it returns seven: two community surfaces, a five-year-old question thread, three seller pages that answer it on the way past, and one newsletter issue written for people thinking of taking the job. Not one page across either set is written for a reader who already has the application.

What the readable pages publish as the work is remarkably consistent. Set technical direction. Choose the architecture and the platform. Hire the first engineers and then manage them. Sit in the room for the diligence conversation. Talk to the board, or to the investor who asked an awkward question. Own the security posture and the vendor list. The Founder Institute’s explainer at fi.co, which its own page data dates 16 July 2024, goes further into the actual mechanics than the sellers do: its list of what the role covers includes “Review codes and define DevOps” and “Help to find and solve technical Issues”, and its separate list for a project audit includes “Evaluation of the code’s quality”. Read that carefully and the pattern holds anyway. Reviewing code, evaluating code and solving a problem in it are three verbs that all sit next to somebody else’s keyboard.

Two of the seller pages describe the role for a whole page without using the word at all. As of 2 September 2026, TechCXO’s fractional chief technology officer service page describes the role entirely in leadership terms, and the words code and coding appear nowhere in its body copy; the only occurrences anywhere in the file are a currency code inside a settings object, a comment in a script and a plugin’s own error message. As of 2 September 2026, the same is true of Ten Mile Square’s fractional CTO capabilities page: the word code appears nowhere in its body copy, and every occurrence in the file sits in theme stylesheets, plugin asset paths and a syntax-highlighting plugin’s own configuration. Those two absences are claims about the bytes of two named pages on one date, nothing wider.

The addresses, in the order of the table: www.amazingcto.com/signs-you-need-fractional-cto/, fractionus.com/blog/fractional-cto-vs-fractional-developers, www.bdemerson.com/article/what-is-a-fractional-cto, fi.co/insight/brief-overview-of-fractional-cto-blog, www.techcxo.com/fractional-roles/cto/, tenmilesquare.com/capabilities/fractional-cto/, and the two that turned the first request away, cto.academy/what-is-a-fractional-cto-and-how-do-you-become-one/ and www.gofractional.com/blog/what-is-a-fractional-cto. None is linked here. Every one of them sells the thing it is describing, or sells education and matching around it, and a link is a recommendation whether or not it is meant as one.

The two addresses at the end of that list have a read history worth stating, because they did not behave alike. Both returned an access-denied interstitial to a plain automated request on 2 September 2026, and both answered a second request the same day once it was shaped the way a browser shapes one. CTO Academy served its whole explainer at 292,402 bytes, and its page data stamps the article 18 April 2023 with a last modification of 4 April 2026, so it is read here in its own words. The GoFractional address served 43,125 bytes that contain the site’s navigation, its footer directory of fractional roles and its generic site title, and no article: that address sits on the site’s blog route with nothing published under it. One of the two is therefore a page, and the other is a slug with nothing behind it.

That last column is the one nobody else prints, and it is the reason the table exists. Seven pages answer the code question. Five of them answer it by pointing somewhere else in the same breath, and the somewhere else is a person or a group of people the reader is assumed to have already.

A note on vocabulary before this goes any further, because two of the neighbouring searches are not this one. Search for the plural of the job by its plainest name and the results change trade completely: job boards take the first and eighth positions, the refinement chips offered are things like remote, job type and date posted, and the result set is written for somebody who wants the work rather than somebody who wants to buy it. That family of searches, fractional cto roles among them, belongs to people looking for the position. It is not this page’s reader and the distinction matters, because a job description written to attract a candidate says what the candidate will be trusted with, not what a buyer will get.

What the role is in the first place, and where the phrase came from, belongs to the page that defines it. Four or five other words circulate for this same job, and whether any of them tells a buyer something real about time or about who signs the contract gets untangled elsewhere.

Do fractional CTOs write code?

Mostly no, and two of the pages holding this search say so in one line. A third says the honest thing, which is that it varies and you have to establish it before you agree to anything. The only page that puts code work on a list of what the role covers puts reviewing and evaluating it there, never writing it, and the one page that answers the question head on calls the coding optional and tells the person doing it not to become the part-time engineer.

The plainest statement of it comes from Amazing CTO, whose article is dated 12 January 2026 in both the publication and modification fields of its own structured data. Writing about what the role is for, its author says: “That’s what a fractional CTO does. Not to write code. To be your trusted technical advisor.” No hedging, no conditions, no depends-on-the-arrangement clause. It is the position of somebody who sells the work, stated as a definition rather than as a preference.

Fractionus, whose comparison of the role against developers carries a byline of 29 October 2025, puts the same boundary in a sentence about altitude: people in this role are “not there to write your codebase”. Its whole page exists to sell the distinction, because the same marketplace supplies both sides of it, and it lists among its own warning signs for a bad match: “The CTO is doing developer work (which wastes their expertise)”. That is a seller telling a buyer that getting code out of this arrangement is a failure state.

B. D. Emerson’s article, whose date plate under the heading reads 25 August 2026, declines to answer the question in the abstract at all. It tells the buyer to settle it with the individual rather than to read anything into the job title, and it says what happens to people who buy one thing hoping to get two: “expecting an executive engagement to also cover implementation is the fastest way to get neither”. The same article carries a section on when the answer to the whole question is no, and one entry in it is as blunt as this market gets: “What you actually need is hands on the keyboard. Hire engineers.”

CTO Academy, a training publisher whose explainer its own page data last modified on 4 April 2026, is the one page here that puts the question to itself and answers it in a line. Asked whether people in this role actively code, it says: “Sometimes, but it’s optional. The job is leveraging: priorities, systems, architecture, leadership, and decision-making.” It goes on to say that coding is useful for short bursts and for unblocking somebody, and that a person who settles into being the part-time principal engineer caps what they can do and leaves the company depending on them. Its list of what the role does not own closes the same door from the opposite direction, ruling out the part-time senior engineer as a shape the work should take. Note who that answer is written for. The word you in it means the fractional CTO, not the buyer, which is a fair description of most of what ranks on this question.

Then there are the two pages that describe the entire job without mentioning code once, dated and scoped above. A reader who takes those two pages at face value would come away thinking the code is somebody else’s department by definition, which is very close to what the other four say out loud.

The honest exception is worth stating because it stops this being a rule. The Pragmatic Engineer newsletter ran an issue on becoming a fractional CTO on 10 January 2023, at newsletter.pragmaticengineer.com/p/fractional-cto, and as of 2 September 2026 the issue is marked for paid subscribers, with only its opening preview rendering to a plain request; nothing below depends on the part sitting behind that wall. In the preview, the practitioner describes what his earliest clients asked him for: help with things like “interviewing their first engineer hires, … or sorting out some AWS issue or some bug”. Sorting out a bug is code work. It arrived because the person was the nearest competent technical adult, not because the arrangement promised it, and that is exactly why the right question is what a specific person will do rather than what the job title means.

One more voice, from the trade rather than from a ranked page. Another practitioner describes the work as filling a gap in technical leadership at an early stage, which is a description of advice rather than of building.

What has to be true for that answer to be good advice?

Somebody else has to be writing the code already. That single unstated condition sits under every answer on these pages, from the bluntest to the most careful, and only one of them says it out loud. Where the condition holds, the advice is sound. Where it does not, the advice is aimed at a company that is not yours.

Amazing CTO prints the premise in the same paragraph as its answer, in the form of an instruction: “You don’t need someone to write code. You have developers for that.” Read that as a sentence about your own situation rather than as advice. It is conditional, and the condition is a team you are assumed to have.

The condition is visible even on the one page that does put code work on the list. The Founder Institute’s explainer has the role reviewing code, evaluating the quality of code, and evaluating the performance of an external team. Every one of those verbs takes an object that somebody else produced, and the third one names the producer outright. There is no version of that list that survives contact with an application whose external team was a text box.

Fractionus, which sells both halves of this and therefore has an interest in the split being real, publishes what the two roles do with their time. For the senior role it gives “10-20% hands-on technical work, 80-90% strategy and leadership”, against “95% hands-on coding, 5% planning” for a developer, and for time commitment it gives “Typically 10-20 hours per week (or 1-2 days)” against “Typically 20-40 hours per week per developer”. Those are one marketplace’s published claims about its own market on a page bylined 29 October 2025, not a measurement of anything, and not an average. Take them at face value for a moment anyway. Nothing here multiplies or divides those figures, and nothing needs to: on that seller’s own account, the technical work is the smaller share of the smaller commitment.

Somebody who runs this kind of practice put the limit plainly: the thing founders come asking for is very often the one thing the arrangement cannot give them.

There is a second assumption, quieter than the first, and it is the one that fails hardest for the reader of this page. As of 2 September 2026, none of the seven pages named above that returned an article uses the phrases AI-generated, AI wrote, written by AI, generated code or code generation anywhere in its bytes, chrome included. Seven files, one date, every string zero, and the eighth address carries no article to check. That is not a claim about the market and not a claim about anybody’s competence. It is a claim about what these particular pages were written to address, and the answer is a company with a team, or a company about to hire one.

Put the two assumptions together and you get the shape of the problem. The advice on offer is written for an owner whose engineers need better direction. The owner reading this has no engineers and a codebase nobody has opened, which is a different hole in a different place. What changes when the code was produced by a builder and nobody has opened it since is argued separately.

What opening the code first means on an application a builder produced

The first piece of work on an application like this is a reading rather than a change. Somebody has to open what is actually there and find out what it does, which is never quite what the running screens suggest. Which parts are wired to something real and which are connected to nothing. Where the data goes and who can reach it. What the tool wrote to make the demonstration work, and what it wrote because a prompt asked for something that no longer matters. Until that has happened, every estimate anybody gives you, including a very senior person’s, is a guess dressed in confidence.

This is the order buyers arrive at on their own once they have thought about it. One owner, asked what to do about an application an assistant had written for them, said they would look for somebody experienced enough to read the existing code first, understand what had been produced, and only then take on the outstanding integration work and the clean-up. Read first, then decide, then do. That is a sequence with a person inside the code at step one. Reading the code is a step some advisory arrangements do include; writing the fix is the step they are defined not to cover, so ask each candidate which of the two their scope names.

There are two ways to buy the reading and they are not the same purchase. One is a paid opinion from somebody who looks and tells you what they see, which is an hour or a few hours of judgement and produces a conversation. The other is a paid examination of the code itself against a stated method, which produces evidence you can hand to whoever does the work next. Paying for the reading itself, evidenced and written down against a named method, is bought from other sellers again, and comparing paid code audit services before you share access is worked through elsewhere. An hour of judgement, bought once from somebody looking at software that is already live, is a different transaction with a different set of limits, and it is written out where it belongs.

Neither of those is direction, and that is the point. Direction is a decision about where the application should go. What this owner needs first is a description of where it currently is, and the two are bought from different people under different words.

Which of the two you need, and what to buy when the gap is building

Advice is the right purchase when the thing missing is a decision nobody in the building can make. Building is the right purchase when the decisions are obvious and nothing is happening to the code. Most owners of an application a tool produced are in the second case and get sold the first, because the first is what ranks.

Three situations where the advice really is the missing piece. You have developers, in-house or hired, and they keep asking you strategic questions you cannot answer, so work stalls waiting on you. Something structural is about to be decided once and expensively, a platform, a data model, a way of handling accounts, and getting it wrong costs a rebuild rather than a fix. Somebody outside is about to look at your technology properly, an acquirer, an investor, a large customer’s security team, and you need a person who has sat on that side of the table before.

Three situations where it is not. Nobody is writing code at all, in which case direction produces a plan with no one to carry it out. What sits in front of you is a list of specific broken things rather than a direction to set, in which case what you need is somebody who will fix them. Nobody has ever read the application, in which case the first purchase is the reading, and any advice bought before it is advice about a description of the software rather than about the software.

Telling those two apart while somebody is quoting you is its own task, and the questions that do it are listed elsewhere. What one costs by the month, the day and the hour, wherever a seller prints a figure, is collected elsewhere. A monthly arrangement with a developer, and which lines of the paper decide whether it was worth paying, is priced where that arrangement is the subject. What one month of a part-time developer actually buys, on an app that is running already, is answered where that purchase sits.

What I do, since it is neither of these

It is not a fractional chief technology officer of either shape, it does not sell direction by the month, and it supplies no standing group of people. That sits outside the comparison above on purpose, because the question it answers is not the one this page has spent its length on.

Common questions about what a fractional CTO does

Does a fractional CTO write code?

Usually not, and the pages selling the arrangement say so themselves. Amazing CTO’s article, dated 12 January 2026, defines the role as advisory rather than as writing code. Fractionus, bylined 29 October 2025, says people in the role are not there to write your codebase and lists a senior person doing developer work among its warning signs. B. D. Emerson’s article, date plated 25 August 2026, declines to generalise and tells the reader to establish it with the individual before agreeing to anything. So the answer for any specific person is whatever they tell you when you ask them directly.

What does a fractional CTO do day to day?

Across the readable pages on this search, the published work is direction and decisions rather than production. Setting technical strategy, choosing architecture and platforms, hiring and managing engineers, handling security and vendors, and being the technical voice in conversations with investors, acquirers or large customers. The proportions vary by seller, and two of the pages describing the job never mention code anywhere in their copy.

What are a fractional CTO’s responsibilities?

The responsibilities published on these pages cluster into four groups: what gets built and on what, who builds it, what happens if something goes wrong, and how the technology is explained to people outside the company. The Founder Institute’s explainer, dated 16 July 2024, is the only readable one that puts reviewing code and evaluating its quality on the list, and even there the verbs are review and evaluate rather than write.

Is a fractional CTO the same thing as a part-time developer?

No, and one of the pages here exists specifically to sell you the difference. A part-time developer is bought to produce code, and the marketplace comparing the two publishes 95 percent of a developer’s time as coding, against the 10 to 20 percent it gives the senior role for technical work. They are two different purchases at two different prices for two different problems, and buying the wrong one leaves the actual gap exactly where it was.

Will a fractional CTO fix a specific bug for me?

That depends entirely on the individual, and the title tells you nothing about it. The one practitioner account readable here describes early work that included sorting out a bug, which happened because that person was available and competent rather than because the arrangement covered it. If a list of specific defects is the reason you are hiring, say so in the first conversation and get the answer before anything is agreed.

Do I need a fractional CTO for an app an AI builder made?

Rarely as the first purchase. Direction assumes somebody is building, and an application a tool produced usually has nobody building and nobody who has read it. The first useful spend is a reading of what actually exists, after which the question of who should set direction becomes answerable rather than theoretical. If the application is already generating revenue and the decisions ahead are structural, the case for the role gets stronger.

What should I ask to find out whether somebody will touch the code?

Ask three direct questions and listen for hedging. Will you personally open the repository and read it in the first two weeks. When something specific breaks, do you fix it or do you tell me who to call. If I have no developers at all, what does your arrangement actually produce in month one. The last one is the sharpest, because the honest answer from an advisory-shaped candidate is a plan and a hiring recommendation.

The questions that expose an advisor-only before any money moves belong to the checklist page for that call.

What do I buy if the work is a list of things to fix rather than a direction to set?

You buy the fixing, from somebody who does that. A list of defects on software that is already live is repair work, and repair work is bought by the problem, or by the batch of problems, from a person or team who will be inside the code rather than describing it. Direction bought against a defect list produces a prioritised version of the same list, which you already had.