The work, precisely scoped.

The starting point for many engagements — particularly where you've inherited an estate, grown faster than the systems supporting you, or simply lost confidence in what's actually running.

I look at what's there, what it's costing, what depends on what, and where the real risks sit. The output is a written assessment a non-engineer can read, with the recommendations ranked by impact and prerequisite.

For when the decision has been made (or is about to be) and you need someone who's done this enough times to spot what's missing from the plan.

My bias is toward zero-downtime migrations where the existing system can keep running while the new one takes traffic incrementally. No big-bang weekends unless they're genuinely the right answer.

New systems, replacement systems, or significant changes to existing ones. The work is as much about constraint as it is about design — what you don't build is often the most valuable decision.

I write architecture documents that read like an explanation, not a specification. Your team should be able to operate the result without needing me on retainer (though that's sometimes the right answer — see S/04).

For organisations that don't need a full-time CTO but do need somewhere to take the technical question before it becomes a technical decision.

Typically a couple of hours a fortnight, plus availability for ad-hoc calls when something time-sensitive lands. The value is in being a calm second opinion that already understands your context — not a generic advisor who needs to ramp up every time.