What to Ask Before Hiring a Fractional CTO, and What Goes Wrong

Hiring a fractional chief technology officer means paying a senior technical person for part of their week, and the version of that hire this page is written for is the one where the app already exists. It runs, it has customers, and most of it was typed by a generator or by somebody who has since moved on. The initials belong to the technology officer, not to the finance or marketing versions of the same arrangement, which the search itself keeps drifting into: on 2 September 2026 a post about hiring a fractional marketing officer sat at rank ten on the questions search, and nine of the eleven completions Google offered for the buying phrase that day were chief-financial-officer wording. Fractional here means part of a week rather than part of an asset. The published question sets that rank for this search were not written for that reader. They grade a candidate against a team, a roadmap, a board and a budget, and the buyer here has none of those in the room.

The questions that decide the hire are about the app you already have: who opens the code, in which week, with what access, and who fixes what they find. The published checklists grade strategy, board fluency and team judgement. Ask both sets, and agree nothing by the month until somebody has read what you own.

The main risk is subtler than an unqualified candidate. A perfectly credible person can give twenty-five good answers, start, and never open the code, because reading it was never part of what they sell.

This page is documented analysis. On 2 September 2026 the fractional-CTO vetting pages holding these two searches were read in their served source, four of them straight away and two more only after the request was re-sent in the shape a browser sends one, and the community thread on the same search could be seen only as a search listing. The owner quoted below is unnamed and unlinked, the pages that already own reading somebody else’s code are linked instead of repeated, and I have never placed, hired, interviewed, tested or run any of the firms or people named here.

Before any of it there is the definition itself. What a fractional chief technology officer actually is, and what the role is understood to cover before anybody sits down for a call, is set out where that definition belongs. This page starts one step later, with a candidate already on the call.

What the published vetting checklists grade, and the question none of them asks

Six pages hold the two searches a buyer runs before this conversation, and all six were read on 2 September 2026, four of them to a plain automated request and two only after that request was re-shaped. Every one is published by a firm that sells the role, a marketplace that supplies it, an agency that offers it or a school that trains people into it, and all six are named here and not linked for that reason.

TechCXO’s twenty-five run from owning a whole technology function, through the first thirty days, what gets produced by day sixty, deciding what not to build, translating engineering cost into business terms, roadmap conflict between product, engineering, sales and the chief executive, execution metrics, resetting a development process that is not working, judging the talent already there, when to use outside development and when to build in-house, managing vendors, integrating artificial intelligence and the risks that come with it, architecture without overbuilding, security while moving fast, technical due diligence for a raise, explaining the technology story to investors, budgets and cost control, when to hire senior people, working with nontechnical founders, disagreeing with the chief executive, operating cadence, and defining success well enough to know when the arrangement should end. Its twenty-fifth is “Why are you fractional?”, and it tells the buyer to ask how many clients the candidate serves, what support network stands behind them, and where they expect to be in two years.

ProfoundIQ’s ten cover vision, decisions made on incomplete information, ownership against advice, how the candidate would review the systems, processes and teams already in place, how priority-zero problems get handled, a philosophy of architecture, hiring and team design, how success is measured in the first sixty to ninety days, how the candidate communicates with founders, and whether they think in phases.

Lemon.io’s seven are moves rather than questions: look for previous business outcomes, test whether the candidate can speak business as well as engineering, ask them to structure the first thirty days, understand why they are fractional, check availability honestly, insist on references that can be called, and run a team check. That last one, in its own words, is a thirty-minute conversation between the candidate and your most senior engineer.

Two more pages rank, and both of them turned a plain automated request away on 2 September 2026 before answering a second one the same day, sent over HTTP/1.1 with a browser user agent. CTO Academy (cto.academy/what-is-a-fractional-cto-and-how-do-you-become-one/) served 292,402 bytes that way and Go Fractional (gofractional.com/blog/cto-interview-questions) served 710,583, and both read histories are printed here because the counts below were taken from those second answers.

Go Fractional’s is the longest question set on either search. Fifty numbered questions in eight groups run from leadership and team management through architecture, infrastructure and operations, security and compliance, product, quality assurance, investor conversations and budgets, and each one carries a line on what to look for in an answer and a line on what counts as a warning sign. Its own page data publishes it on 24 December 2023 and modifies it on 13 August 2026, and it closes with a section on hiring through the marketplace that published it. CTO Academy’s page is a different animal: most of it is addressed to the person becoming one of these rather than to the person buying one, and its buyer-facing part is a five-item warning list. What that list warns about is the buyer’s own house rather than the candidate. No sponsor who can decide anything. A mandate to fix everything. Accountability handed over without decision rights. A company where every request is urgent. A company hiring a hero instead of building something that works without one.

Read all six and the same shape appears in every one of them. Most of the questions assume a company with engineers to assess, a roadmap to argue about, a board to explain things to and a budget line to control; the ones about availability, motivation and how the person communicates need none of that. The two that needed the second request shape sharpen the point rather than soften it: Go Fractional’s fifty ask a candidate to build a delivery pipeline from nothing, staff a rota for out-of-hours failures, prepare a technology budget and negotiate with vendors, and CTO Academy’s own answer on what a founder should have ready before the first call asks for access to stakeholders, a current roadmap, an architecture overview, key metrics, a delivery history, a team structure and the real list of known issues. The reader who searches this phrase after a generator built their app has none of that. They have one application, some paying customers, no engineer to put in a thirty-minute call, and a codebase no one has been through from end to end.

Across the readable copy of each of those six pages, navigation and footer included, on 2 September 2026: the words repository, GitHub, existing code, generated code and vibe appear zero times, and the phrase read the code appears zero times. Three of those terms do turn up in raw source, on two of the six pages, and every match is invisible to anybody reading the page. On the TechCXO page a bundled browser-detection library carries a github.com address in its header comment, and a developer’s comment on a form handler reads “Your existing code (keep as is)”. On the Go Fractional page an editor permissions string inside the site’s own build data lists a connect-code-repository right three times, and GitHub occurs four times inside a skills taxonomy, twice as a tag name and twice as its slug. The word codebase appears once on the ProfoundIQ page, twice on the Lemon.io page and once on the Go Fractional page, and those four exceptions get named here, because an absence claim that hides its own exceptions is worth nothing. ProfoundIQ’s single use is the title of another of its posts in a related-reading strip. Lemon.io’s two are a promise about what a good candidate will do in the first few weeks, and a line about structuring a codebase sensibly at pre-seed. Go Fractional’s one sits in a passage on quality assurance that describes what an experienced technology officer brings to a stack and a codebase already in place, which is a statement about the person rather than something the buyer is told to ask about.

Four items come nearest the app you already own. ProfoundIQ’s fourth question tells founders to ask how a candidate would audit the systems, processes and teams already in place, and its own answer puts reviewing code quality among the things that assessment covers. A warning-sign item on the SeeSaw Labs page says “Strong partners ask sharp questions about your code and team before prescribing solutions”, which describes what a good candidate does rather than a question the buyer is told to put. Go Fractional’s quality-assurance passage says an experienced technology officer will “incorporate technical due diligence to assess the underlying technology stack and codebase for scalability, security, maintainability, and risk management”, which is the nearest any of the six comes to the code a buyer already owns, and one of its security questions asks a candidate how they would run a technology audit, though that one is aimed at regulations and standards rather than at what the app is made of. Not one of the four tells the buyer to ask who opens the code, in which week, and who pays that person.

So the gap has nothing to do with the quality of those pages. They are written for a company that has a technology function to lead. Grading somebody who will do the work themselves, on one named job, takes a different set of questions, and those are written out where that hire is decided.

Six questions about the app you already have

One owner who had paid for an application said the honest problem was that they had no way of telling whether the work underneath was any good, because they could not read it themselves. That sits underneath every question below, and it is the one thing none of the ranked question sets picks up. The whole of what that owner wrote, in their own words, sits on the page about the owner who paid for an app and could not judge what came back.

Six questions get at it. Each one has an answer that commits the candidate to something, and a part it still leaves open, which is the part to ask about next.

Three of the six carry most of the weight.

Who opens the code, and in which week. A candidate can answer this in one sentence, and the sentence tells you almost everything. Somebody who names a week, an account they need and a first thing they would look at is describing work. Somebody who answers with an assessment period, a discovery phase or a review of the technical direction is describing a meeting. Both answers are honest. They are not the same purchase.

The people selling the role say so themselves. TechCXO, a firm that supplies fractional executives, closes its own twenty-five questions with this: “A fractional CTO does not need to personally write every line of code. In most cases, that is not where they create the most value.” Its FAQ answers the question the same way, saying close involvement does not require writing code, though it does require being deep in architecture, delivery, team performance and technical risk.

Take that seriously, because a no to this question says nothing bad about the candidate. The arrangement they sell works exactly the way its sellers describe it, and what matters is the sentence after the no: who does open the code, when, and who pays for that person. Whether the person in front of you is meant to advise or to build is an argument with a settled answer, and it is made where that split belongs.

If you find something serious, do you fix it or write it down for somebody else? ProfoundIQ’s third question puts the same split from the seller’s side, asking whether a candidate will take ownership or only offer advice, and its own answer stays at the level of technical direction, planning discussions and decision-making forums. It warns that involvement limited to periodic check-ins or high-level commentary produces limited results. That is a fair warning and it stops short of the buyer’s version, which is simpler: if the person finds a problem in week two, does anything happen, or does a note appear?

Ask for the last time it happened. A candidate who has done this before will tell you about an app, a problem and who ended up doing the work. A candidate who has always had a team to hand the work to will describe the process instead, which is worth knowing before you agree anything, because you do not have that team.

What part of this would you not do yourself? This is the question that ends the conversation early in the useful cases. Nobody answers everything. The good answers name a boundary and then name who covers the other side of it, and the cost of that person is a real cost whether or not it appears anywhere in what you are quoted. What changes about every question here when a generator wrote most of the app and no person has read it through is taken up elsewhere.

Questions about the shape of the month

The second set measures how much of this person you are actually getting, and what happens in the three weeks when nobody is in a meeting with you. Competence is not what it tests.

How many other clients are there right now? Lemon.io, a marketplace that supplies these people, states the norm in its own guide, read 2 September 2026: “A fractional CTO typically works with two to four clients simultaneously.” It follows that with advice to get clarity on the candidate’s other commitments before starting. TechCXO’s last question does the same work from the other end, telling the buyer to ask how many clients somebody serves and what support network stands behind them. Neither page treats several clients at once as a problem, because that is the model everybody in this market works to. The trouble is only ever the gap between that model and what a buyer assumed they were getting.

How many hours, and on which days? An answer in hours is checkable. An answer in availability is not. Ask which days, because a candidate who is somewhere else on the two days your app gets its traffic has told you something a weekly hours figure hides.

What happens between sessions? The honest versions of this answer are narrow and specific: questions get answered within a working day, or on a shared channel, or not at all until the next session. All three are workable. The unworkable one is the answer that implies constant availability without saying what it covers, because that gets discovered on the first bad evening.

Who answers when it breaks at an awkward hour? Ask for the name, not the arrangement. Part-time senior people are usually not on call, reasonably enough, so the question is who is, and whether that person exists yet.

How does this end? TechCXO’s twenty-fourth question asks candidates how they define success and know when it is time to move on, and ProfoundIQ asks how success gets measured in the first sixty to ninety days. Both are asked from the seller’s side. From yours the question is plainer: what would have to be true for this to stop, and what do you keep when it does. A candidate with a clean answer to that is describing a relationship with an exit. One without an answer is describing a subscription.

One warning sign is published on the marketplace side and worth borrowing. Lemon.io calls it a red flag when a candidate insists you will need them for half their working time before they have looked at anything at all. The reason it is a red flag is the same reason this page exists: nobody can size this work honestly before somebody reads the app.

What one costs by the month, in the figures providers publish about themselves, is collected where those numbers are read. The paper behind a monthly arrangement, and what the sellers who publish a price for one charge, is gone through where those pages are read. And what a month of a part-time developer’s availability actually contains, once an app is live and running, is settled where that decision is made.

What goes wrong after a fractional CTO starts?

Five failures show up after the start rather than at the interview: advice nobody is placed to act on, an application that never gets read, availability agreed before anyone has looked, an arrangement that outlives its reason, and an ending with nothing written down. Every one of them is visible in what the sellers themselves publish.

Advice with nobody positioned to act on it. This is the failure ProfoundIQ names from the inside when it warns that involvement limited to periodic check-ins produces limited impact. The buyer’s version is worse than the seller’s, because a company with an engineering team can at least act on good advice. An owner with one app and no engineer receives a plan and then has to go and buy somebody to do it, which is a second purchase nobody mentioned during the first one.

The app never actually gets read. None of the six pages read on 2 September 2026 tells the buyer to ask who opens the code, in which week, and who pays that person. ProfoundIQ’s fourth question comes closest, asking how a candidate would audit the current systems, processes and teams, with its own answer including code quality among the things that assessment reviews. The firm at the top of the search states plainly that writing the code is usually not where the value sits, which is a point about writing rather than reading. Put those together and the risk is clear: weeks of decisions being made about an application that no party to the decision has read, unless the buyer asks who reads it, whether the candidate does that reading or delegates it, and who pays for it. When it surfaces, it surfaces as a question nobody can answer, usually a simple one about how long something will take.

Availability agreed before anybody has looked. A month of somebody’s time is agreed at a number that suits the seller, who knows no more about the state of the app than the buyer does. Lemon.io’s warning about the candidate who wants half their time up front is the polite version. The general case is any commitment sized before a reading, in either direction: too much time bought for a short list of work, or too little bought for an app with real problems in it.

The arrangement outliving the reason it was bought. Somebody is brought in to get through a bad quarter, the quarter passes, and the sessions continue because cancelling them feels like a risk. TechCXO’s own checklist treats knowing when to move on as a question worth asking a candidate, which is a fair sign it happens. Write down at the start what would make this stop.

An ending with nothing written down. The last one is the least dramatic and can be the most expensive. A part-time technical lead accumulates the only map of your app that exists, in their head, over several months. If the arrangement ends without that map coming out of it in a form somebody else can use, you are back at the start, minus the money. Ask on the first call what you keep when it ends.

What no question settles, whoever you hire

No answer in an interview tells you the state of your app. Three things stay unknown until somebody has actually gone through it, and honest candidates will say so.

How long anything will take. Whether what is already there can carry the next feature you want, or has to be reworked to take it. And what is broken now but not visible yet, which is the category nobody can price from the outside.

That is a reading job, and it is a different purchase from a monthly arrangement with a technical lead. Choosing the person who will read the code, and what a bought review has to produce before it is worth the money, is decided where that purchase gets compared. The first week of somebody going through an app they did not write is laid out day by day elsewhere, and it is a useful thing to read before the call, because it tells you what a serious answer to the access question sounds like.

Handing the technical side over for good is a bigger decision than buying part of somebody’s week, and it is not the decision on the table here.

The questions that come before these

Two decisions sit in front of this conversation, and neither of them is answered on a candidate call.

Whether the situation calls for this hire at all, rather than for one repair with a finish you could watch, is decided before any of these questions get asked. Where these candidates are found, and how the buying runs from a first approach to an agreed start, is covered separately.

If both are already settled and somebody credible is on the call next week, the questions on this page are the ones worth the hour.

Common questions about interviewing a fractional CTO

What if the candidate says they do not write code?

That answer is normal and it is what the market publishes about itself. TechCXO’s own checklist, read 2 September 2026, says a fractional CTO does not need to personally write every line of code and that in most cases it is not where they create the most value. The follow-up is the part that matters: if not you, then who reads the app, in which week, and who pays that person. A candidate who has a clear answer to that has thought about buyers like you. A candidate who treats the question as unusual has not.

How many clients does a fractional CTO usually have at once?

Lemon.io states in its own guide, read 2 September 2026, that a fractional CTO typically works with two to four clients at the same time, and advises getting clarity on those other commitments before anything starts. TechCXO tells buyers to ask the same thing, along with what support network the candidate has behind them. Several clients at once is the model rather than a warning sign. The thing to establish is which days you get and what happens on the days you do not.

What should I ask about the first thirty days?

Ask what gets opened, not what gets produced. A plan for thirty days that names accounts, an application and a first thing to look at is a plan somebody has run before. A plan that names workshops, alignment and a technology direction can be delivered without anybody ever seeing your app. Both may be offered by good people, so ask which one you are being sold, and then ask what the second thirty days depend on.

Can I ask somebody to look at the code before anything is agreed?

Yes, and how a candidate reacts to being asked is itself information. Some will do a short look for nothing, some will price a first reading separately, and both are reasonable positions. The answer to watch for is the one that dismisses the idea as unnecessary at this stage, because a monthly commitment agreed before anybody reads the app is a number built on a guess by both sides.

What if I have nobody technical to sit in on the call?

That is the ordinary case for an owner whose app was generated, and it is the assumption the ranked question sets do not make. Lemon.io’s vetting list, read 2 September 2026, recommends a thirty-minute conversation between the candidate and your most senior engineer, which is advice you cannot use if there is no engineer. The workable substitute is a question whose answer you can check later against something real: names, weeks, accounts, and one specific finding from one previous app. A technical friend brought in cold is the weaker option, because they get one hour of context and then have to judge somebody on it.

Which of these questions matter most once the app has paying customers?

The access question and the ending question. Paying customers turn every unknown in the code into something with a cost attached, so how quickly somebody can be inside the app and reading it is worth more than their board experience. The ending question matters for the same reason: with real users, being back at the start with no written record of what was learned is a genuine setback rather than an inconvenience.

What are the warning signs in a fractional CTO interview?

Three of the published lists are worth reading side by side. TechCXO’s ten cautions include a candidate who talks mostly about tools without asking about the business, who cannot explain a technical problem in plain language, who recommends a rebuild before understanding the product, customers, team or constraints, and who has no support network beyond their own time. Lemon.io flags the candidate who insists on half their working time before they have looked at anything. CTO Academy’s five point at the buyer instead: no sponsor who can decide, a mandate to fix everything, accountability without decision rights, a house where every request is urgent, and a company shopping for a hero. Those three lists were read on 2 September 2026, as was Go Fractional’s warning line under each of its fifty questions. The sign none of them carries is the one that matters most here: an interview that ends with no clear answer about who opens the code.

How should the arrangement end?

With a date or a condition agreed at the start, and with something written down that another person can pick up. TechCXO’s checklist asks candidates how they define success and know when to move on, which suggests buyers should ask the same before signing. The practical version is three sentences in whatever you both sign: what would make this stop, how much notice either side gives, and what you keep. The last one is the one people forget, and it is the expensive one.