Phil Powell
Fractional CTO for founder-led SaaS
Closing the gap between how systems actually behave and how a business believes they do.
The most expensive problems in software businesses rarely live inside the technology. They live in the gap between how systems actually behave and how the organisation believes they behave.
Every organisation runs on a model of its systems — how the software behaves, how work moves through the business, what depends on what, and what can safely change. The systems keep moving. The model lags. I work in that gap, closing it while it's still a correction, not yet a crisis. The usual first move is an Engineering Health Diagnostic.
The Engineering Health Diagnostic → Compare notes on LinkedIn →
Based between the UK and Austria, working in English across the UK and DACH.
The moment I help with
Most companies don't reach this point because engineering failed. They reach it because the product worked.
Early decisions got the company moving. A small team shipped quickly. Customers arrived. The roadmap expanded. And the business started depending on systems, people and habits built for an earlier stage.
Then the same signs tend to appear:
- Releases are harder to trust, even when the change sounds simple.
- Technical debt is discussed often, but rarely translated into business risk.
- You, or one senior engineer, are still needed to explain how everything works.
- The team is busy, but it's hard to say what's actually improving.
- Compliance, reliability, or scale is becoming unavoidable rather than optional.
None of this means engineering has failed. It means the model the business runs on — what's automated, what's fragile, who knows what, what's safe to change — has quietly separated from the systems it describes.
That separation always has a cost, even when nobody has named it yet — and it's far cheaper to find than to wait for. That's what the diagnostic is for.
The Engineering Health Diagnostic
Most technical reviews audit the technology. This one audits the gap.
I start with your model: what leadership believes is automated, stable, nearly done, well understood, and safely changeable. Then I check that model against the evidence — the code, the pipelines, the incident history, the delivery data, and who actually gets asked when something breaks. The findings are the places where belief and behaviour have separated, what each gap is costing, and what to close first.
It's built for founder-led SaaS companies, typically 5–40 people, where the technology already carries real weight: revenue, sensitive data, compliance, or operational dependency.
Usually the gap builds slowly, as the business outgrows the systems and habits it started with. It can also open suddenly, at a leadership transition. When a founder steps back, an MD or CEO steps in, or new investment arrives, the incoming leadership inherits the business but not the model of it: in a founder-led company, much of the understanding of how everything actually works lived in the founder's head, and it doesn't transfer with the org chart. The gap is at its widest exactly then, which is why the diagnostic often earns its place in the first months after a handover.
What you get
- A findings memo — 8–12 pages, plain English, written for the founder. Every finding takes the same shape: what the business believed · what's actually happening · what the gap is costing · what to do first. No finding without a cost; no cost without a first move.
- A first-moves page — one page, ordered. Some moves your existing team can take on themselves; others need sustained senior judgement, and the page is honest about which is which.
- A readout conversation — 90 minutes, you plus whoever you want in the room. The memo is what you keep; the conversation is where it lands.
- A follow-up call — 30 minutes, two weeks later. What moved, what stalled, and what that says about the conditions you're working in.
What a finding looks like
The same four-part shape every time. Four examples below — each a belief that turned out not to match the evidence. (Drawn from prior leadership roles; details altered.)
What the business believed: the overnight reconciliation job was automated — a solved problem, and had been for six months.
What was actually happening: a senior engineer checked it by hand every morning, because of a silent failure found once and never fixed. The automation existed; the trust didn't. The check lived in one person's routine — not the runbook, not the monitoring, no one else's head.
What the gap was costing: an unpriced single point of failure on a revenue-bearing process, and a knowledge dependency the business didn't know it had. If that engineer left, the first sign would have been a customer.
What to do first: not a rewrite. Alert on the failure, name an owner, retire the manual check in a fortnight.
What the business believed: every change was peer-reviewed before release. The process was documented, and reported as followed.
What was actually happening: reviews had quietly become rubber stamps. Under deadline pressure the team learned a fast approval kept things moving, and the one engineer who still read the code closely was treated as a bottleneck.
What the gap was costing: a quality control leadership counted on, and didn't have. The defects it was meant to catch were reaching production and being written off as bad luck.
What to do first: review what carries risk, and stop reviewing what doesn't — a practice that means something on the changes that matter, not a ritual on all of them.
What the business believed: releases were slow because the product was complex — the fair price of quality.
What was actually happening: every release was run by hand, in the evening, from a checklist two people trusted and nobody else understood. It worked, so no one questioned it.
What the gap was costing: not the time — the caution. The team batched changes to avoid releasing, so releases grew bigger, rarer and riskier, which made everyone more cautious still. The "cost of quality" was a brake on the roadmap.
What to do first: make one release boring. The aim isn't speed; it's breaking the loop where fear of releasing makes releasing more dangerous.
What the business believed: the company was audit-ready. Compliance evidence was produced and filed every quarter, and the audits passed.
What was actually happening: the evidence existed because one person assembled it by hand from systems that didn't talk to each other. The audits passed on their memory, not the company's records.
What the gap was costing: an unseen single point of failure on something the business had told customers it had under control. If that person was away at audit time, "compliant" became "unable to prove it."
What to do first: not a compliance project. Make the evidence fall out of how the systems already run, so passing the audit stops depending on one person's recall.
Four beliefs, one pattern: a gap between what the business takes to be true and what the evidence shows. Behavioural Drift and Why Your Roadmap Keeps Slipping take that pattern apart at length.
Shape
Two weeks, start to finish.
Week one is conversations and evidence gathering. I talk to whoever holds the most context — the founder, others in leadership, a product owner, the senior engineers, and the touch points in other teams who feel problems first — for an hour or so each, scheduled around their work. Because the subject is the systems, not just the code, that usually reaches beyond engineering.
Week two is synthesis, the memo, and the readout.
Read access to repositories, pipelines, and incident and delivery tooling is required; production access is not.
What it isn't
- Not an audit of the team's competence. Most companies reach this point because the product worked, not because engineering failed.
- Not a rewrite recommendation in disguise.
- Not a compliance gap analysis, though it will surface where compliance exposure is accumulating.
- Not a long report nobody reads.
£7,500fixed
≈ €8,700
Agreed scope, agreed artefacts, no day-rate meter running.
What the fee covers
- A findings memo
- 8–12 pages, plain English, written for the founder.
- A first-moves page
- Ordered, and honest about what your team can take on alone.
- A readout conversation
- 90 minutes, you plus whoever you want in the room.
- A follow-up call
- 30 minutes, two weeks on — what moved, what stalled.
Two weeks, start to finish.
The fee isn't credited against any follow-on work. The diagnostic is complete in itself — if the right outcome is that your team executes the first-moves page without me, it has done its job.
Where it leads
The diagnostic stands alone. Three things tend to follow from it:
- You execute it yourselves. The first-moves page is written to make this possible.
- Outcome-based engagement — one finding becomes a focused piece of work: a stabilisation, a migration path, release confidence, compliance preparation. Typically 2–12 weeks.
- Fractional CTO — where the findings point at direction, decision-making and the operating rhythm of the team rather than any single system. Typically 1–2 days per week, growing out of the diagnostic's priorities rather than a generic engagement.
Nothing is pitched in the readout. If a continuation makes sense, it surfaces at the two-week follow-up, where there's evidence to base it on.
Proof
I've spent much of my career stepping into environments where technology already carried real responsibility — vulnerable users, sensitive medical data, operational risk, external compliance — and the cost of misunderstanding it was never theoretical.
Across CTO and senior engineering roles, I've built engineering functions from scratch, rebuilt fragile legacy platforms into reliable production systems, delivered zero-downtime migrations of mission-critical infrastructure, and led organisations through ISO 27001, ISO 22301 and ISO 9001 certification and external audits.
Alertacall. I joined as the sole engineer on technology that vulnerable people relied on to live safely and independently. The company grew from a small startup into an organisation of more than seventy people, and the technology had to grow with it. I built the engineering function from scratch, modernised legacy systems, rebuilt core signalling infrastructure, and helped create a platform that could carry real operational demand without losing service continuity.
Medical Tracker. I joined a product with real usage, sensitive medical data, a large backlog, and no engineering team in place. I built the function from the ground up, introduced delivery structure and QA discipline, modernised infrastructure, and helped the platform mature as the business scaled. It went on to pass ISO 27001 and ISO 22301 audits with zero non-conformities.
The pattern is consistent: structure brought to complexity without losing the ability to work practically inside the details.
How I think
Everything above is built on one idea: the expensive problems live in the gap, not the technology. A few principles that follow from it:
The CTO should not be the system
If one person has to remember how everything works, approve every important decision, or explain every trade-off, the business hasn't built a technical function — it's built a dependency. Good leadership reduces that over time.
Technical debt is only useful when translated
A backlog of debt doesn't help a founder decide anything. The useful questions are: what risk does this create, what does it slow down, what could it cost, and what happens if we leave it alone?
Stabilise before you scale
Growth exposes weak points. It doesn't fix them. Before adding more people, more process, or more roadmap pressure, it's worth understanding what's already fragile and what needs to be made safer first.
These essays take that idea at full length — where it comes from, and how it plays out in systems and delivery.
- Behavioural Drift — how software systems stop behaving like themselves, and why a system that works and a system you understand quietly stop being the same thing.
- Why Your Roadmap Keeps Slipping — why slippage is a property of the system rather than a failure of effort, and why the usual responses — more planning, more control, more people — tend to make it worse.
- At Eye Level — where the habit of looking for the gap comes from. Every system encodes a model of the person who'll use it — and that model is always narrower than the world it meets.
About
I'm a CTO and senior technical leader with a background in SaaS, platform modernisation, engineering leadership, reliability and compliance. I work where business pressure meets technical complexity — the point where founders need clearer judgement, engineers need stronger direction, and the organisation needs its technology to become more dependable without slowing everything down.
I'm also registered as severely sight impaired. It shaped how I think about edge cases, resilience, and the distance between how systems are expected to behave and how they behave under real conditions — it's where I first learned to look for the gap. I've written about that in At Eye Level. I notice assumptions, weak signals, unclear ownership, and the places where a system is quietly relying on ideal conditions.
I'm based between the UK and Austria, working in English across the UK and DACH.
Close
Engineering problems rarely arrive all at once. They accumulate. A shortcut becomes a dependency. A workaround becomes the process. A senior person becomes the documentation. A fragile release becomes normal. I help companies recognise that moment while it's still a correction, and close the gap before it gets priced in.
If any of this matches what you're seeing inside your own company, I'm always glad to compare notes.