What a Fractional CTO Actually Does – Nick Sales on Product, Teams and AI

Nick Sales set out to be a journalist, spent a summer in Silicon Valley in the late eighties, and changed course so completely that he went straight into a PhD in neural networks and natural language processing. He came out of it in 1995, directly into the second AI winter, when there was almost no funding for the field at all. What followed was investment banking, a Fortune 500 software house through the second-largest leveraged buyout of its time, nearly twelve years at EY, and finally a deliberate move to working as a fractional CTO. In this episode he talks to Rob Woodhead about what the role actually involves, how to price work when the value is judgement rather than hours, the mistakes he sees founders make with technology, and why someone who has studied AI for thirty years thinks the current wave has overreached.

Key takeaways

• A fractional CTO holds a senior leadership role across several companies at once, working on outcomes rather than a fixed number of hours.
• Retainers work better than day rates for this kind of work, because effort is lumpy: some weeks demand seven days and others half an hour.
• The most expensive early-stage mistake is paying for development on a time-and-materials basis with no design process behind it.
• Founders should understand their business model before building anything beyond a prototype, because build it and they will come remains the most common fatal assumption.
• A development agency usually beats hiring a single developer, because costs are explicit, capacity can scale, and testing and security expertise comes as standard.
• Vibe coding is genuinely useful for prototypes and unsuitable for high-security production software.
• AI code generation is strongest on the code it has seen most of, which means websites, and weakest on rare or hard-to-find languages.
• Studies are beginning to show AI-assisted development can lengthen total end-to-end time rather than shorten it.
• Adding AI purely to satisfy investors produces no defensible advantage, though the funding pressure driving founders to do it is real.

Episode chapters

• 01:42  From wanting to be a journalist to a summer in Silicon Valley
• 03:46  A PhD in neural networks, straight into the second AI winter
• 06:53  Naples, an internet provider, and a backer who vanished
• 08:28  Investment banking and running global market risk engines
• 13:34  Why outsourcing to the lowest bidder pushed him into software
• 14:45  Becoming a manager with no training for it
• 16:55  Being told a CTO role would suit him, before CTOs were common
• 17:39  Why having real software testers mattered
• 19:17  SunGard, 85 businesses and the second-biggest leveraged buyout
• 21:54  Watching Lehman Brothers collapse from the footbridge
• 24:06  Twelve years at EY instead of the planned two
• 26:26  Going fractional, and the Berkeley CTO programme
• 28:19  What a fractional CTO actually is
• 32:36  Why retainers work better than day rates
• 36:46  The technology mistakes founders make
• 39:00  Why an agency usually beats hiring one developer
• 41:36  Vibe coding: fine for prototypes, risky in production
• 42:25  Tech for good, and building for accessibility
• 49:04  Thirty years of AI, and where GenAI is now
• 54:00  Whether AI is eroding developer skill
• 01:03:30  When founders add AI just to raise funding
• 01:08:36  If the consultancy were a band

What is a fractional CTO?

A fractional CTO carries out a senior technology leadership role for several companies at once, giving each of them a fraction of their time. The commitment varies widely, from half a day a week to ten days a month, and the person is genuinely doing the job rather than advising from a distance.

The distinction Nick draws is between hours and outcomes. A fractional executive is not there to occupy eight hours a day and work through whatever appears. They are there to deliver specified outcomes, which is how leaders operate generally and what makes the arrangement workable across multiple clients.

He is dryly aware the label has been over-adopted, noting that roughly a billion people now describe themselves as fractional something. Setting the terminology aside, the pattern applies across CTO, CMO, CISO, CFO and COO roles.

It also sits close to the interim CTO, which is usually full-time and often brought in to turn something around or cover a sudden departure. In practice the line blurs, and even a fractional engagement can run at full intensity for a stretch.

We work with fractional CTOs on client projects regularly, because it gives a founder an independent senior technical view on architecture and scaling decisions without a full-time hire. You can read more about how we work with clients.

How does fractional CTO pricing work?

On retainers rather than day rates, in Nick’s case, and for a specific reason.

The workload is uneven. Engaged for two days a week, he might genuinely need seven days one week and half an hour the next, because something upstream slipped or because everything landed at once. Priced by the day, that becomes an argument every month. Priced against outcomes, it becomes irrelevant.

The mechanism that makes it fair is a review cadence. Every week or two at the start, then every two or three weeks, both sides look at the actual effort the outcomes required. If it has consistently run high, they agree to raise the fee or reduce the scope. If it has run low, the same in reverse. The adjustment is mutual and expected rather than a renegotiation.

Nick reports most clients grasp this immediately, often before he finishes explaining it, because the value being purchased is judgement. Thirty seconds of “do not do that” from someone who has seen it fail seven times is worth more than a day of anyone’s time.

What technology mistakes do early-stage founders make?

Nick separates them into business mistakes and technology mistakes, and the most expensive one sits on the boundary.

It is paying developers on a time-and-materials basis to build something specified through conversations and back-of-envelope sketches, with no formal design process. His description is that this is an efficient way to stop worrying about the size of your bank account. He has watched it happen more than once.

The second is going beyond a proof of concept or prototype without understanding the business model. Build it and they will come is still the dominant failure, and he has a good analogy for the ideas that trigger it: the innovations catalogues that used to fall out of magazines in the eighties and nineties, full of technologies combined in ways nature never intended. Slippers with torches in them, for instance.

Rob’s addition is that thorough planning feels slow and makes the overall build shorter, because the alternative is discovering the thing you failed to consider halfway through.

Should you hire a single developer or a development agency?

Nick’s advice leans firmly towards an agency, and he lists why.

Costs are explicit rather than emergent. Capacity can scale up and down as the work demands. You get skills you did not know you would need, which matters because early-stage teams reliably discover requirements they could not have anticipated. Someone can start within a week or two. And testing and security expertise comes as part of the package rather than as an afterthought.

The risk with a single developer is concentration. His phrasing is that Dave down the road, working from his garage, might get a job at some point, and then where are you? The technical debt is one problem. The single point of failure is a different and larger one.

Rob is sympathetic to why founders do it anyway. Funding is scarce, they often have a technical friend, and they want something in front of users quickly. The difficulty is that one person is rarely strong across every part of the problem, which is why the transition to a team tends to happen eventually.

Worth noting on testing: Nick has been asked, in the last couple of years, why software needs testing at all, on the assumption it will simply work.

You can see the products we have built and read about how we structure delivery teams.

Is vibe coding safe for production software?

No. Nick is unusually direct about this, and worth quoting closely: vibe coding is immensely valuable for many kinds of prototype, and it is not a suitable technique for building high-security production-quality software.

The underlying reason is about training data. These models are best at the code they have seen most of, and because they were trained substantially on the web, they are strong at building websites. Move to less commonly published code, or a genuinely obscure language, and the quality falls away. Even on well-represented open-source code, the way generalisation works in neural networks makes errors inevitable rather than occasional.

Rob’s framing at Old St Labs is a hard distinction between code assist and vibe coding. AI helping an engineer write code is a productivity tool. AI writing code nobody then reviews is a different activity with a different risk profile, and the two get conflated constantly.

If you have inherited or generated a codebase you are not certain about, that is exactly what our Vibe Code Audit assesses. The Jekyll and Hyde of Vibe Coding sets out the two failure modes in more detail.

Is AI making developers less skilled?

Nick is concerned, and the evidence is more mixed than the marketing suggests.

On productivity, studies are starting to indicate AI-assisted development can take longer overall than writing the code directly, with an increase in total end-to-end time. He is willing to accept that trade if the additional time is going into security and review, since the work has shifted from writing to verifying. What he is less willing to accept is the claim of straightforward speed gain.

The deeper worry is skill formation. If earlier-career work gets automated away, developers may never pass through the stages that produce mid-level and senior engineers. His analogy is the ten thousand hours adage: ten minutes writing a prompt does not make anyone an expert, whereas researching and writing a paper yourself leaves you genuinely more knowledgeable, because the thinking is the point rather than the typing.

Interestingly, Rob’s experience at Old St Labs runs slightly counter to the fear. The senior engineers have become the pragmatic adopters. The junior engineers have asked to keep learning the fundamentals, on the reasoning that without them they cannot judge whether generated code is any good. Rob also relays a striking data point from computer science lecturers in the Philippines: coursework completed at home scores well, and the same students score considerably worse in supervised lab work without AI access.

Should you add AI to your product just to raise funding?

Nick is sympathetic to the pressure and unwilling to do the work.

He acknowledges the situation plainly: AI has become close to a gatekeeper for funding, and a founder saying they need to do some kind of AI is making a reasonable business request rather than a naive one. He also thinks this is one of the real risks of the current cycle, because capital is being diverted away from sound non-AI businesses towards anything carrying the label.

If a client asked him to build the whole application with GenAI, he would decline. No moat, no quality.

What he does instead is more useful. AI is a large field, most of which is not generative, and machine learning in particular is a mature toolkit. So he looks for a technique genuinely suited to the problem the business actually has. His line on this is the best summary of technology selection in the episode: do not buy a giant golden hammer and then call everything a nail, especially when it turns out you manufacture wine glasses.

It is worth remembering how long this field has existed. AI research dates back to the 1940s, and many AI technologies are so embedded and so effective that we stopped calling them AI at all. They have been in phones, televisions, washing machines and microwaves for years. Nick’s view, from thirty years inside the discipline, is that generative AI specifically may have overreached.

About the guest

Nick Sales is a consulting technology and business success leader working as a fractional CTO with growth-stage companies, focusing on product strategy and the technology side of M&A. He holds a PhD in neural networks and natural language processing from Imperial College, and has previously led technology at a Fortune 500 software house and spent nearly twelve years at EY. He recently completed an 18-month CTO programme at UC Berkeley. His current clients include GrowWise, a hospitality and food and beverage business, and Moveable, which is working on the rental market. He is particularly interested in technology for good and in accessibility, including colour blindness, age-related changes to vision and hearing, and neurodiversity.

About the host

Rob Woodhead is a co-founder of Old St Labs, a London-based software agency building web and mobile products for startups and innovators, with a delivery team in the Philippines. He and Nick met through a monthly London gathering of tech founders.

Frequently asked questions

What is a fractional CTO?

A fractional CTO performs a senior technology leadership role for several companies simultaneously, giving each a portion of their time, commonly between half a day a week and ten days a month. The engagement is measured by outcomes delivered rather than hours worked.

What is the difference between a fractional CTO and an interim CTO?

An interim CTO is usually full-time and engaged for a defined period, often to lead a turnaround or cover a departure. A fractional CTO works with multiple clients concurrently on an ongoing basis. In practice the two overlap.

How much does a fractional CTO cost?

It varies with scope. Nick Sales works on retainers rather than day rates, with the fee reviewed regularly against the effort the agreed outcomes actually required, adjusted upwards or downwards by mutual agreement.

Is vibe coding safe for production?

No. Vibe coding is well suited to prototypes but not to high-security, production-quality software. AI models perform best on the code types they have seen most, and generalisation makes errors inevitable, so generated code needs expert review before it ships.

Should a startup hire a developer or an agency?

An agency is usually the safer choice early on. Costs are explicit, capacity scales, testing and security expertise is included, and you avoid depending on one person who may leave. A single developer is also unlikely to be strong across every part of the build.

‍