Principal Software Architect / Telemetry at scale · R&D · On-prem AI
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 someone describes a system that doesn't exist yet and asks whether it can be built.
I say yes more often than is comfortable, and then I go and prove it. Recently that has meant telemetry architectures managing millions of active network devices, an enterprise platform moved off public cloud onto bare metal in a month against a one-year estimate, and on-premise language models doing automated root cause analysis inside networks where data is not permitted to leave the building.
Prototypes are arguments you can run.
The pattern repeats: build the smallest working artefact, put it in front of people expecting a slide deck, and let it end the argument. One observability app I built from scratch existed for exactly one reason — to answer a customer RFP with something running rather than something promised. A demo that works ends a debate a document never will.
That was the research bench. I've since stepped off it entirely and into product — architecting and building a large system from zero. Different game: a proof only has to survive the demo, whereas a product has to survive its own success. Same instincts, much longer horizon.
The breadth is deliberate. I came up writing production code, spent real time in interface design, and did the unglamorous security work — custom server builds, penetration-test remediation, hardening. 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, and which assumption an attacker will lean on first.
Architecture without hands-on execution is opinion. I still build, and I insist on specification-driven development rather than improvisation — the blueprint exists before the code, and it is written down. The diagrams are downstream of the building, not the other way round.
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 succeeds — the load, the team size, the integrations nobody has asked for yet. Boundaries, data flow, failure modes and security posture go into a written specification first. Spec-driven development isn't bureaucracy; it's the difference between a system and an accumulation of decisions nobody remembers making.
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.
Enterprise systems decomposed into reusable services, with the specification written before the code and the trade-offs recorded rather than remembered.
Designing for the day it fails, not the day it launches. Upgrades that don't require a maintenance window, and a recovery path that has actually been rehearsed.
Server-side systems where the language is chosen for the job — Go where throughput and footprint decide it, JVM and Node where the ecosystem does.
Storage picked for the access pattern, not the résumé. Columnar and time-series where data arrives continuously from millions of sources; relational where correctness outranks ingest rate.
Models inside the customer's perimeter doing real operational work — root cause analysis over drifting log formats, with retrieval designed as architecture rather than bolted on.
Cloud when it earns its cost, on-premise when the data isn't allowed to leave — and the experience of moving a live platform between the two without users noticing.
A threat model belongs in the first architecture review, not the pre-launch audit. I've done the unglamorous end of it — custom server builds, hardening, and closing what penetration tests actually found.
Authentication, authorisation and secrets treated as infrastructure with an owner — not as a library each service integrates slightly differently and nobody can audit.
04 — Case studies
All of this is real work. Employers and products stay unnamed on purpose — the shape, the constraint and the result are what matter.
Also shipped
05 — Trajectory
Nobody arrives at architecture. Each stage added a lens the previous one didn't have — and I still use all five.
Off the research bench and fully into product: architecting and building a large system from zero. Owning the thing rather than proving it's possible — specification first, then the platform that has to live with those decisions for years.
Telemetry platforms across millions of devices, a cloud-to-premise migration, on-premise LLMs for automated RCA, and reusable enterprise services. Entrusted with high-stakes R&D at executive level.
Golang services as a solo contributor, Kubernetes with NGINX and Consul to close critical vulnerabilities, and a core rewrite that found 80% more performance without touching the public API. The lens: what a system actually costs to run.
Modules built ground-up across Angular, Go, Node and Java, a framework redesign that halved resource consumption and tripled speed, and a reporting framework shipped solo. The lens: owning something end to end changes how you design it.
Custom server builds, automated configuration migration, and remediating application and database vulnerabilities surfaced by penetration testing. Code keeper for the team, on the change control board with onshore clients. The lens: assume it will be attacked.
Large-scale data migrations and a legacy J2EE application modernised onto Spring — plus interface wireframes shipped with zero regressions. The lens: someone has to use this.
06 — Selected work
Professional work stays unattributed. 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.
Statistics and visualisation for pandemic data, built entirely client-side — no backend, no database, no server to keep alive. Public sources fetched and rendered in the browser. An exercise in making a fast-moving, messy dataset readable at a glance with nothing behind it.
Experiments, spikes and half-finished ideas. The unglamorous raw material that the polished work comes out of.