When I was assigned to work on a new product under the SolarEdge ONE for C&I umbrella, I was keen to avoid the same process issues I'd seen between design and engineering that slowed work on our main platform. Issues such as drift between design snapshots and live designs, and lack of synchronicity between our components in code and the corresponding ones in Figma. Our designer was already well underway with design work, but I proposed building the design system together, from the start, rather than trying to retrofit later.

We decided to follow the Design Token Community Group (DTCG) standards and implement a three-tier design token system (primitive/semantic/component), but decided to allow Figma's component model to carry the component layer implicitly. We also decided to be strict about only using semantic tokens in Figma components, and try to follow "Atomic Design" principles when designing components, so we could maintain the same levels of component abstraction between design and code.

In code, I mapped the primitive layer in JSON, then created a staged factory pipeline to generate the semantic layer and component "token contracts" at runtime. The "token contracts" concept provided a mapping back to the component model in Figma. And the whole abstraction mapped well onto styled-components' theme model, the styling technology chosen for the project. Using Figma Code Connect to link each component back to Figma meant drift and compliance could be monitored at the tooling layer.

Where design and engineering had been separate stages with handoffs and reconciliations between them, they were now operating as one process, integrated at the tooling layer, but more importantly at the communicative one.

Working on a new product under the SolarEdge ONE for C&I umbrella, I was tasked with adopting an AI-first approach in engineering. The prevailing view in the wider industry (at the time), was that AI tooling could handle backend work but couldn't do UI. After a few days of watching Claude Code fumble on a few test cases, I could see why people thought that. But I didn't think this was an AI problem. I thought it was a system problem. I believed that for AI to be effective in the UI space, the gaps between design and code needed to be systematised.

I pitched to our CEO for time to establish this structure. Arguing that our current approach to UI engineering relied heavily on a shared undocumented knowledge built up across the team over time. A model with no access to that knowledge would almost certainly fail (in the same way a new starter with no onboarding would). So the first step in "adopting an AI-first approach to engineering" was to systematise every part of the design-to-code process.

With the foundations in place, I built a component-builder skill that read a component from Figma, scaffolded it from Radix primitives, referenced shad-cn for well-designed, accessible composition patterns, applied the correct tokens via styled-components, and produced the Storybook and Code Connect files alongside it. Component creation went from hours to minutes. A screen-builder skill extended this. Given a Figma frame, it audited the existing library, flagged gaps for component-builder to fill, and once those were addressed, produced the screen.

I deliberately stopped short of orchestrating these into a fully automated loop. PRs still needed to be human-sized to review. And the point of the work was to establish AI-first engineering workflows, not replace the engineer altogether.

Coming out of an "AI-Hackathon" day, the prevailing assumption was that our current platform was too old and too complex to support production AI features. Couple this with the assumption that any AI feature would be chat-bot shaped, and it felt like the takeaway was "All of this is fun and impressive, but not for us right now". I felt the opposite, that the enterprise architecture could be an asset, and that generative UI could be a much better product fit for a data-dense application. I spent some down time the following week to find out.

A production-ready generative UI feature needed to hit two marks. It needed to be treated as an unprivileged consumer, and any generated UI needed to look like it was signed off by our designer. The prototype I created broadly followed this pattern:

• The UI interaction called our tRPC API like any other.
• The tRPC procedure handled the input; defining the system prompt, combining it with parameters from the UI, and selecting which tools the LLM would have access to.
• It kicked off a server-side background job that ran the agent loop, with bounded retries on validation failure.
• The agent loop lived in a service sitting adjacent to our standard BFF services, acting as a thin, typed wrapper that exposed "tools" to the LLM as hooks into existing platform capabilities, with all permissions enforced by the underlying services.
• The LLM produced its final answer by calling a tool with a structured UI descriptor, validated by Zod.
• Another tool exposed a curated component registry, telling the LLM what UI it could compose.
• To avoid blocking the UI (LLMs take their sweet time), a web worker polled for completion and triggered a notification button state change when the result was ready
• When the user opened the result, a dynamic renderer walked the descriptor tree, looking up each component in the same registry the LLM had access to, and rendering it via wrapped versions of design-system components with constrained prop surfaces.

What I wanted to put in front of the team was a demonstration that the very things assumed to be challenging to build around were exactly the pieces that enabled AI features in production.

The Explorer module (and several others I worked on) contained data-dense interfaces such as dashboards combining tables, charts and real-time readings, pulled from a set of generic platform services, processed and served via a backend-for-frontend (BFF) before being sent to the browser.

The recurring engineering problem within the existing architecture given data containing thousands of data points across hundreds of assets, was doing the work in the right place in the stack, preventing the backend from being hammered whilst also not grinding the browser to a halt.

This usually required me to collect together all data required by a specific UI across backend services into the BFF, iterating over it a single time, and shaping the UI response using lookup tables, sets and maps, with tRPC and Zod handling contracts at both boundaries. This meant that the BFF could serve data in the general shape the UI needed without having to do all of this work in the browser.

In the UI itself, maintaining a container/view split in most cases meant I could have the container orchestrate and make any further transformations it needed to feed multiple child views, for example processing a single large dataset for use in both chart and tabular format.

The devil being in the detail, the challenge was holding all of this in mind at once, deciding when to push work up or downstream, employing selective memoization, breaking out frequently updated components from long-lived ones, but not going so far as to over abstract and increase maintenance. The judgement was being able to take current work in context with future work, as well as considering the type of scale and use a feature was likely to see, to forecast where the next bottleneck was likely to arise.

Scoped and delivered a key feature for a FTSE 250 client on a commercially critical timeline, protecting a strategically important relationship.

Raised the level of frontend rigour within a full-stack team through code review (emphasising "why" over "what") and steering planning toward existing patterns over novel solutions, compounding consistency over time.

One of the core goals of the project has always been long-term sustainability, and my choices of technology reflect that.

Astro was selected as the frontend framework to enable the site to be statically generated, ensuring it could be served from anywhere should the underlying content operations side of the project need to be wound down.

Sanity was selected as the content platform to provide an easy way for project members to manage the site whilst providing a generous plan for non-profit orgs.

The projects are deployed to Cloudflare Workers. Cloudflare was chosen because you can start with zero complexity and cost, and scale both only as you need to. Perfect for a burgeoning non-profit.

These technology choices have proven to be an incredibly powerful combination, each being able to be extended as the desire for more complex features arises. For example, our LLM-driven content auditing feature was made possible by Sanity's excellent extensibility and MCP tooling, and Cloudflare Workers serverless functions and KV storage.

My initial contributions to the project were purely delivery focused. There was already preliminary designs for the website, and my role was to put together a prototypal working version that could be taken forward.

Following initial user feedback, a subsequent UX consultation, and a number of strategic pivots, I was engaged to figure out what would be required to get the project to a finished state.

Working closely with the project owner I executed a full redesign of the website and was brought in to execute the final implementation.

One of the challenges non-profit projects face is financial. In a content heavy project such as this one, it is essential to dedicate enough resource to content editing. But full time content editors are not cheap.

In response to this challenge I implemented an LLM driven 'Content Editor'. Using Sanity's excellent MCP infrastructure, the Claude platform, and Cloudflare Workers, I was able to create a virtual content editor that audits content on a schedule, making changes as necessary, ready for human review.

This significantly reduced the workload associated with content operations and is now mostly the process of human review and approval of AI output.

Produced an operational plan covering future development, content ops, maintenance and costs, giving the project lead a concrete pitch for donors and partners.

Every decision I made on the project had to satisfy two opposing constraints; the product had to ship fast enough to be ready for the trade show in December, and it had to be scalable and maintainable enough for a future team to keep building. Anything novel or experimental risked stability; anything too heavyweight risked velocity. I settled into picking battle-tested but modern tooling for the foundations, reserving any appetite for risk for novel product features.

This approach can be demonstrated with the choice of React Query (now TanStack) for server state and Zustand picking up the small amount of genuinely client-side state that remained. This was at a time when Redux was still the go-to choice for "production apps" but I was keen to avoid a lot of the complexity that Redux would bring. These slightly off-piste tool choices proved worthwhile in how quickly I was able to ship, and how light I was able to keep the codebase.

At this time, Redux was still the default choice for production apps, but I was keen to avoid the complexity and heavy boilerplate it would introduce. As such I opted for tools like React Query (now TanStack) for server state, and Zustand for managing the genuinely client-side state that was left. These tools allowed me to build a thin API for the UI, exposing per-resource hooks like useProjects, useRisks, etc. Yup handled validation at the API boundary, both as runtime safety and to catch backend contract drift during a time of rapid development (in hindsight I wish I'd have bet on Zod too).

The biggest stakeholder conversation was about MUI. The CEO had high expectations for design fidelity, but building accessible, edge-case-resilient components from scratch (particularly the data grid the product was built around) would have burned valuable runway. I made the case that they were paying me to build a product, not a component library, and that MUI with a custom theme gave us most of what we needed (we could always build custom later if/when we needed to). They agreed, and we never had to revisit it.

The Lexical integration for our timeline feature was the one place I deliberately took a risk on a less established tool. The CEO wanted a Slack-like rich text experience for comments. Draft.js was on the way out, there were a few other options, but Lexical's plugin style architecture felt like we wouldn't hit a ceiling with it, and as it was already being used in Meta products, it felt like an educated gamble.

The thread across all of these decisions was making the choices that served the product's stage and the client's goals. The job was to ship something that worked quickly, that could be built upon well into the future.

In late 2022, shortly after ChatGPT 3.5 launched, the CEO wanted to know whether we could use the OpenAI APIs to populate user's projects with "starter risks", generated from a project description, so they didn't have to waste time on inputting the "obvious common risks" (but risks that still needed to be tracked). The patterns and tools we now take for granted (structured output, function calling, mature JS SDKs) didn't really exist yet. There wasn't even a common set of terms for talking about LLM driven features like there is now.

The hardest engineering problem wasn't getting the model to produce reasonable suggestions; it was getting it to produce parseable, schema-conformant data reliably enough to render a UI from. I'd already been experimenting with "prompt engineering" and had techniques for coaxing JSON output against a given schema. I worked with the backend engineer on how to construct a prompt with injected user content (there wasn't even a separate 'system' and 'user' message at this point), and we worked through the end-to-end integration.

These early models were unpredictable so we created a defensive layering pattern. The backend (being weakly typed), tested for compliant JSON in the response and simply mapped the output to the correct properties. In the frontend, leveraging the Yup schemas I already had modelling the domain, I used Yup transformations to normalize what I could, drop what I couldn't use, and discarded the whole result if not enough survived, which felt like the best approach deal with the probabilistic output of the model.

The feature shipped and to my knowledge remains in production as part of the Enterprise tier. At the time it felt like magic, a user could write a few sentences about their project and the system would populate itself saving them hours of work. The patterns I used here, particularly schema validation as the trust boundary between an LLM and UI, are ones I've used in similar work since (thankfully we now have the tooling that makes this much easier). The key thing at the time, as it is today, was to design the system to fail gracefully rather tha catastrophically when the models misbehave.

When I joined RAIDLOG, there was no real engineering process. Whilst there was a well developed PRD, work was primarily delivered as long-lived branches to main with no clear scope or priority. As more of us came on to the project (myself on the frontend, a new backend engineer), that pattern started causing actual harm (merge conflicts, overwritten work, and no clear understanding of what everyone was working on or what features would be next to ship). This created contention in early meetings, for example "When will X be ready?", when we weren't sure as engineers what "X" was defined as.

The existing team were receptive to resolving this tension, most never having worked on a software project of this nature. As me and the backend engineer were subcontracted from the same firm, we framed the conversation as "help us help you". Using the Github platform that was already hosting our code, we surfaced to the Product Manager (new to this kind of role) the tools available for managing delivery. We started by defining features as Issues, supporting the PM with intent, scoping and acceptance criteria, and breaking that down into specific tasks (using GitHub's markdown task lists to make progress visible on a ticket). Once we were settled into that, we started using Github's Milestones and Kanban board features which made it possible to forecast where we'd be by a given date, but more importantly, made scoping discussions possible.

Our goal was always to provide just enough structure to make decisions, and to facilitate conversations about scope and delivery. As the PM grew in confidence they took ownership of the processes and made them their own, in the meantime it made our jobs of delivering on the project in line with expectations much easier.

Authored an architecture recommendations document for CTO ahead of contract end, advising on framework migration and strategies for scaling the frontend beyond the startup phase.

Working on behalf of a client partnered with major UK cancer charities, I was assigned to deliver a mobile app enabling patients to keep track of their symptoms, quality of life, experience of care and costs. There were also plans to deliver a web app shortly after mobile release, but not necessarily the time or budget to deliver separate applications.

To solve this, the app was built as a React web application shipped inside a Xamarin WebView, enabling cross-platform release from a single codebase. The scope didn't warrant the overhead of a heavier setup, so I built it in plain JavaScript with React and Tailwind, no additional libraries. Consciously avoiding external dependencies and over engineering meant it was built and shipped in a matter of weeks and would require very minimal maintenance over time.

It went live in booth app stores on schedule and deployed to the web shortly after.

Working for Health Education England, I delivered the frontend for an ePortfolio system used by healthcare professionals to record learning resources from across the internet. As a public sector organisation, the system was legally required to meet WCAG 2.1 level AA.

The work that mattered most here was learning the standards deeply enough to implement, and defend them when necessary. This often meant pushing back on client requests that would have failed the standard such as color palette changes that did not meet minimum contrast requirements or font size reductions aiming to fit more information on screen. It also meant having to make substantial changes to the design as the project progressed, both as I understood the standards better and as testing revealed gaps that hadn't been visible earlier.

The system passed its accessibility audit on go-live. The main thing I took from the project is that accessibility is not just a checklist at the end of the project. When done properly, it needs to be designed in from the beginning and defended throughout.

My first professional development project was a desktop app for a small yacht management company, taking their payroll spreadsheet to produce and email PDF wage slips. The work involved Excel ingestion, pixel-perfect PDF construction, and email delivery.

Thankfully I was naive to the pain that each of these areas can hold and just battled through, one obstacle at a time, without any understanding of whether it was meant to be difficult. The app shipped, satisfied the immediate business need, and led to further work with the client.

I like to reflect back to this project whenever I find myself working on something that seems impossible. It's a handy reminder that we don't always know a solution up front, and that's ok, the important thing is to keep moving and eventually, we get to the end.