> story
The story so far.
How I got here, what I built along the way, and the principles that shaped how I think about software and the people who build it.
before the code
Ten years in sales
I spent a decade in telecom retail — selling phones, broadband plans, and home electronics to everyday people. Customer-facing, service-minded, technically curious. I was always the one explaining what the products actually did under the hood. That job gave me something I still draw on: an instinct for what makes something genuinely useful to the person on the other end of it, and a comfort with talking to non-technical people about technical things.
finding the craft
KYH frontend programme, 2018
I enrolled in KYH's frontend development programme in 2018. It was project-based from day one — no dry theory, straight into building things with teams. We learned agile the way you actually learn it: by doing standups, missing deadlines, retrospecting, and doing better. I came out with a solid React and JavaScript foundation, a habit of iterating quickly, and a real respect for the discipline of writing maintainable code. In parallel I was taking on small commissions — sites for friends, local businesses, the occasional redesign — enough to know this was where I wanted to go.
svea solar, 2020 – now
From frontend engineer to lead
I joined Svea Solar's sites team in 2020 and spent four years going from building pages to owning the platform they ran on. The headless CMS, the lead capture system, the Salesforce API integration, the analytics layer — I built all of these incrementally, taking on ownership as the system and my understanding of the business grew. In 2024 I moved into the lead engineer role. Now I run a team of 2–5 developers across the full stack — TypeScript on the frontend, Python (Wagtail) on the backend. That shift from individual contributor to lead has been the most interesting challenge of my career so far.
> philosophy
How I think about the work
Get the foundations right
Features are temporary. The content model, the data contracts, the CI pipeline — those live forever. Every time I've rushed past an architecture decision I've paid for it later, and every time I've slowed down and thought it through I've been grateful. I'm not precious about it — I can move fast when the situation calls for it — but I've developed a strong instinct for when to pause and get the structure right first. A morning spent on the right abstraction is worth weeks of untangling a bad one.
Code you can actually trust
I build components in isolation — pieces that know their own shape and API without caring where they end up in the application. That forces genuine reusability rather than coupling to the page they started on. Paired with a Cypress suite for critical user paths and Jest for logic-heavy pieces, you get a system you can refactor without second-guessing everything. Tests aren't a tax on development. They're what give you permission to keep moving confidently as the codebase grows.
Raise the ceiling
When I moved into the lead role I realised quickly that my output as an individual engineer was no longer the most important variable. What matters more is whether the people I work with are growing, whether they understand the system well enough to make good decisions without me, and whether they feel real ownership over their work. I try to be generous with context, curious about how people think rather than prescriptive about solutions, and honest when I don't know something. The goal is a team that makes good calls when I'm not in the room.
Not done yet.
I came from sales, spent years as an engineer, and recently stepped into a lead role. Each shift was a deliberate bet on what I wanted to be good at. I'm drawn to hard problems that sit at the edge of what I know — the kind where the answer isn't obvious and the architecture has to be thought through carefully. If you're building something interesting and want someone who thinks about both the code and the people building it — let's talk.