Principal Software Architect / R&D · Prototypes · Systems at scale
I work at the front of the line — where the requirement is a hunch, the feasibility is unproven, and someone has to build the thing that shows it can be done. Research, prototype, prove, then harden it into production.
01 — Profile
Every box is a decision, not a default. Hover any node for the reasoning behind it.
Most of my career has been spent one step ahead of the roadmap — in R&D, in discovery, in the room where a client describes something that doesn't exist yet and asks whether we can build it.
I say yes more often than is comfortable, and then I go and prove it. That means writing the spike myself, standing up the infrastructure, wiring the interface, and putting a working artefact in front of people who were expecting a slide. A demo that runs ends an argument that a document never will. A meaningful share of the deals I've supported were won on the strength of a prototype rather than a proposal.
Prototypes are arguments you can run.
The reason this works is breadth. I came up as a senior software engineer, spent real time in UI/UX design, went deep on cybersecurity, and have run my own ventures. So when a system needs designing I'm not just drawing boxes — I know what the code will feel like to write, where the interface will frustrate someone, which assumption an attacker will lean on, and what the whole thing costs to run.
Architecture without hands-on execution is opinion. I still build. The diagrams are downstream of that, not the other way round, and they're better for it.
02 — Method
Five stages. The first two are where the risk actually lives — most projects fail long before anyone writes a line of code that ships.
Before scope, before stack. I work with stakeholders to separate what's actually being asked from what's being described, and pin down the constraints, the success metric, and the one assumption that would sink everything if it were wrong.
I build the smallest thing that answers the scariest question — a spike, a throwaway service, a clickable flow. Feasibility gets settled with evidence in days, not debated in meetings for weeks. This is where deals get won and bad ideas get killed cheaply.
Once the answer is known, the architecture gets drawn for the system as it will be after it has succeeded — the load, the team size, the integrations nobody has asked for yet. Boundaries, data flow, failure modes, and the security posture, decided deliberately and written down.
I stay in the codebase. Reviews, pairing on the hard parts, and setting the patterns by writing them rather than mandating them. Architecture that the people implementing it don't believe in is just documentation.
Automated pipelines, containerised delivery, and instrumentation from day one — because a system you can't observe is a system you can't defend or improve. Then the loop restarts with real data instead of guesses.
03 — Capabilities
The stack below isn't a wish list. It's what I've shipped with, debugged at 2am, and made architectural decisions about.
System decomposition, service boundaries, data modelling and integration strategy — with the trade-offs written down so the next person understands why, not just what.
Server-side systems and the storage layers under them — chosen for the access pattern rather than the fashion, and sized for what happens after launch.
Front-ends that make complex systems legible. Heavy on data visualisation — the fastest way to make an abstract architecture feel real to a non-technical room.
A threat model belongs in the first architecture review, not the pre-launch audit. Hardening, secure-by-default design, and the discipline to assume the perimeter has already failed.
Repeatable, automated, observable delivery. Containers and pipelines so that shipping is boring and the interesting problems stay in the product.
Architecting around foundation models rather than bolting them on — retrieval, evaluation, cost and failure behaviour treated as first-class design concerns, not afterthoughts.
04 — Case studies
Client work sits behind NDAs, so the sectors stay vague and the shape stays honest: what was asked, what made it hard, what I actually built, and what it changed.
05 — Selected work
Client work mostly lives behind NDAs. These are the ones I can point at.
A progressive web app for organising and managing YouTube playlists, driven entirely by a JSON source so the whole thing stays extensible without a backend. Offline-capable, installable, and deliberately small.
Real-time statistics and visualisation for pandemic data — an exercise in making a fast-moving, messy dataset readable at a glance under genuine traffic.
Experiments, spikes and half-finished ideas. The unglamorous raw material that the polished work comes out of.