What I’d actually do as your fractional CTO

You’re bringing someone in because something needs to change. Perhaps the product isn’t moving fast enough. You’re making technology decisions you don’t feel qualified to make. Or the business is growing, and the way you’ve managed engineering until now is no longer working.

You need someone who can understand the situation, make sound decisions and take responsibility for getting things moving.

That doesn’t have to start with a long-term commitment. We can begin with a specific problem, a defined piece of work and an agreed budget. An ongoing fractional role may make sense, but it shouldn’t be the starting assumption.

I’ve founded businesses, built software myself and led engineering teams through growth and funding rounds. Here’s how I’d put that experience to work in your business.

1. Understand the business before prescribing the technology

Before recommending a platform, a hire or a rewrite, I’d want to understand how your business works.

Who pays you? What are they paying for? What brings customers in, and what causes them to leave? What commitments have you made? How much time and money do we have to work with?

I’d also want to understand what prompted you to bring me in. “We need to move faster” could mean a customer is waiting for an integration, the product hasn’t found its market, or the team is spread across too many priorities. Those require different responses.

We’d agree on the outcomes that matter and the constraints around them. That gives us a basis for deciding which technology work deserves attention and which can wait.

2. Get into the code and work with the team

I still write production code. I wouldn’t assess your technology solely through presentations and conversations with managers.

I’d work with the engineers to understand the architecture, review representative parts of the codebase and follow a change from request through to production. Where does it stall? Who makes decisions? How do we know it works? What happens when a release goes wrong?

Alongside that, I’d examine risks that could materially affect the business: access controls, sensitive data, dependencies, backups and reliance on particular people.

This isn’t about finding fault with the team. Engineers often know where things are getting stuck but lack the authority, time or support to address them.

You’d get an evidence-backed view of what’s working, what’s fragile and what needs further investigation. I’d distinguish confirmed problems from things we haven’t yet verified.

3. Follow the money, including AI costs

I’d look beyond engineering salaries to contractors, agencies, infrastructure, software subscriptions and third-party services. That includes AI subscriptions, API charges and token usage, whether they sit inside development tools or the product itself.

I’d want to connect those costs to useful work. Which features, customers or workflows are driving consumption? What happens to the bill as usage grows? Are we paying for repeated attempts, unnecessary processing or expensive models where a simpler approach would do?

A low token bill doesn’t tell us much if someone spends hours correcting the output. Equally, higher AI spending may be worthwhile if it reliably removes substantial work. I’d examine the total cost of completing the task, including integration, human review and rework.

The objective isn’t indiscriminate cost-cutting. It’s understanding what we’re spending, what we’re getting and where a change would genuinely improve the economics.

Where the data is incomplete, I’d make that clear rather than present estimates as precise figures.

4. Check whether AI is actually helping

I’d review how AI is being used, not simply whether the business has adopted it.

What problem is it solving? What does success look like? How are we checking accuracy, handling failures and controlling access to data and systems?

For engineering teams, I’d look beyond how quickly code is generated. Can the team explain it, test it, review it and maintain it? Is AI helping deliver reliable software, or producing more work that somebody else has to untangle?

For business workflows, I’d assess the result against the alternatives. Sometimes a model or agent is appropriate. Sometimes a straightforward integration, a few business rules or a better process would be simpler and more reliable.

I’m interested in AI that earns its place through a useful result. I wouldn’t recommend adding it just to make the product sound more advanced.

5. Separate urgent problems from things that can wait

An old framework isn’t automatically a business emergency. An unreliable backup or exposed customer data may be.

I’d prioritise problems by their consequences: customer impact, security exposure, revenue, operating cost and the work they prevent us from doing.

For each significant issue, I’d explain what could happen if we leave it alone, how confident we are in that assessment and the smallest sensible response. A contained fix may buy us the time we need. A larger change should earn its place against other priorities.

“The code is messy” is not enough to justify a rewrite.

The result should be a short, actionable list with clear owners, alongside an explicit decision about what we are not fixing yet.

6. Take ownership of getting work delivered

You shouldn’t have to wait for an assessment to finish before anything useful happens. Where the evidence supports a decision, I’d act.

That might mean reducing the scope of a release, settling an architecture decision, resolving a supplier dependency or helping an engineer get a difficult change into production. I’d write or review code where that is the best use of my time.

It also means being willing to stop work. A team can be fully occupied delivering things the business no longer needs.

We’d agree my decision-making authority early so everyone knows what I own and what still needs your approval.

The aim is visible progress without creating a new dependency on me. Decisions should be documented, responsibilities clear and the team better equipped to move the next piece of work forward.

7. Agree on the next step, not an open-ended programme

The scope and pace should reflect the problem and the time we’ve agreed.

A focused review is different from taking over a complex platform or changing how an engineering team operates. I’d explain what we can establish quickly, what needs deeper work and when you’ll have enough information to make the next decision.

At an agreed checkpoint, we’d review what we’ve learned, what has changed and what still needs attention. Any further work should have a clear outcome, owner, cost and realistic timeframe.

You might need ongoing support. You might need help delivering one important change. Or your existing team may be able to take it from there.

The value should stand on its own, whether or not the engagement continues.

---

You should come away with a clearer understanding of your technology, confidence in the important decisions and progress on the work that matters.

That’s what you’re paying for: sound judgement, hands-on capability and someone accountable for moving things forward.

Tell me what is holding your business back, what you’ve already tried and what needs to happen next.