I build the whole thing.

I learned to code from hackathons, books, and a computing course at college. No computer science degree upfront — just enough practical knowledge to be dangerous. At 18 I joined Accenture as a degree apprentice, working five days a week while studying remotely for a software engineering degree.

Accenture's apprentice intake was varied — no guarantee whether you'd end up in software, testing, business analysis, or something else entirely. I landed in a manual test role. Within six months I'd turned that around by finding a problem nobody had the expertise or appetite to solve: a batch monitoring application spanning 20,000 jobs across mainframe and Tivoli schedulers. I built tooling to visualise complex batch systems — PHP, mainframe extracts, Oracle DB — and gained a reputation as the person who could make invisible infrastructure legible.

That reputation opened doors. People started championing me for increasingly complex technical problems — which eventually meant being the person thrown into recovery projects. I moved into Angular and .NET at a financial services firm, building authentication packages, API dashboards, and a tool that generated sequence diagrams from integration code to help defect triage teams understand what was actually happening between services.

The pattern was set early: find the problem nobody owns, build something that makes it visible, earn the next problem. I wasn't waiting for tickets. I was looking at what the team needed and building it.

A senior architect I worked with had built a graph-based engine that could represent user journeys as directed graphs — nodes for activities, edges for transitions, declarative validation. What was missing was the rendering layer: the part that takes a graph node's JSON schema and turns it into interactive UI that developers could actually use.

I built that layer. Dynamic component generation, recursive rendering for nested structures, an override system for custom components, and packaging it all as a distributable module. It started as a side-of-desk project with no budget and no deadline — just spare capacity and a good collaborator.

The platform got demoed to a global payments company and sold on the strength of a working prototype. I was brought in to lead the delivery — a team of 12 developers, integrating the platform with their existing application, cutting their frontend delivery estimate from 2022 to 2020.

Two weeks after offboarding, the NHS needed an emergency MVP for their Covid test-and-trace centre finder. The platform was portable enough to reuse. I supported the deployment, upskilled their junior developers, and moved on to define frontend architecture at the Bank of England.

That sequence taught me more about product engineering than any single engagement could. It also taught me that a rendering engine manipulating the DOM at a low level has a real testability problem — unit tests give false confidence when engine state and render output are tightly coupled. It's a genuine architectural tradeoff I'd approach differently now.

In 2021, after two years of back-to-back high-pressure engagements — the rendering engine, the payments delivery, the NHS emergency, the Bank of England — I burned out. I took three months off.

Up to that point, I had a clear trajectory: become an architect. That's why I'd been deliberately moving across stacks — frontend-heavy work at a financial services firm, then the rendering engine and leading frontend teams, then defining architecture at the Bank of England. The plan was to build deep expertise in every layer so I could credibly shape entire systems.

The break forced me to question whether that was still what I wanted. I came back and did something different: pure DevOps on a government programme. Red Hat OpenShift, Tekton pipelines, HashiCorp Vault, ArgoCD, networking, monitoring, security clearance. Infrastructure from the ground up. Not because I'd given up on the architect path, but because I wanted to understand the platform layer properly — not just the applications that sit on top of it.

After six years at Accenture — from new associate to senior analyst, from mainframe batch jobs to Kubernetes platforms — I moved to Red Badger. A smaller consultancy. Fewer layers. At Accenture I was building real products, but I was often the person thrown into a recovery — firefighting delivery problems, rescuing timelines, leading teams through pressure. Red Badger was different: embedded in cross-functional teams from day one, shaping the product alongside design and product people, not parachuting in to save it.

My first engagement was an exams management platform. We shipped an MVP in 100 days — 4,000 exams, 45 users, 3 countries. Over the next year I helped scale it to 250,000+ exams, 900 users, 85 countries. Full-stack with DevOps: React, C#, GraphQL, Playwright, Kubernetes blue-green deploys. For the first time I wasn't recovering someone else's delivery — I was building from scratch, making tradeoff decisions with the team, watching real users interact with what we'd built. That was the shift. I fell in love with product work.

Then I tried other things. Nuffield Health — a charity maintaining nuffieldhealth.com across a Java CMS, Ruby on Rails, and Django services, all handed over by different consultancies. It taught me what happens when products are built without long-term ownership: layers of well-intentioned code from teams who moved on, and the people left holding it trying to make sense of the joins.

After that, a logistics startup — One World Global Trade. Leading the frontend team, shifting them from a development-first mindset to involving designers and QA from inception. Building Spring Boot microservices. Designing an authorisation model to replace a tactical solution. Every startup is different. This one taught me that the gap between a startup's ambition and its engineering reality is where a senior engineer adds the most value — not writing the cleverest code, but making the right structural decisions early enough that they compound.

I came back to Red Badger. The product-focused consulting model fit how I wanted to work: embedded in cross-functional teams, building real products, moving across domains every few months. Since returning, I've worked on a global retail brand (React, Node.js, GraphQL — cut build times by 60%), technical consulting for a privacy-focused tech company (picked up Rust and Crux in three weeks), a community engagement platform for a higher education institution, and now a client onboarding platform for a wealth management firm where I co-designed the workflow orchestration service in Rust. The work has me revisiting concepts from my early career rendering engine — configuration-driven flows, graph-based journeys — now applied to onboarding orchestration in Rust, with the benefit of knowing what I got wrong the first time.

On the side, I design and build for small businesses — like RenoPlumb, where I ran four interactive design concepts past a three-person plumbing team, shipped the winner, and validated it with PostHog analytics. That's the work I find most satisfying: research to design to code to proof. The full loop, with no handoffs.

I operate across the full stack — React, Rust, TypeScript, infrastructure, design. Not because I can't specialise, but because the most important decisions happen in the gaps between layers. The choice of where to put validation logic. Whether a loading state earns or erodes trust. How an event-driven workflow shapes what the interface can promise the user.

The architect path I planned at Accenture turned into something different and better. I don't want to draw the boxes — I want to build what's inside them. Consulting taught me to read a system fast, earn trust fast, and deliver fast. Product work taught me that speed without taste is just technical debt with a launch date.

I care about whether the thing works for the person using it — not just whether the code is clean.