Coding
I've spent the last few years working across the full frontend stack, mostly in React and TypeScript, building tools for e-commerce teams and internal platforms. Here's how I think about the work.
Scaling front-end architecture at Zoa
When I joined Zoa, the front-end was built with Bootstrap and Sass. As the product grew, this made it difficult to maintain consistency, ship complex features, and scale development across the team.
Problem
UI patterns were inconsistent, components were tightly coupled, and adding new features often meant duplicating logic or introducing regressions.
What I did
- Migrated the front-end to React and TypeScript
- Introduced a component-driven architecture
- Built a shared component library using Storybook
- Defined reusable patterns for data fetching, forms, and validation
Why
The goal wasn't just to modernise the stack, but to create a system that made it easier to build consistent, predictable UI and support more complex product features over time.
Outcome
- Reduced UI inconsistency and duplication
- Enabled more complex features (e.g. reactive Shopify integrations)
- Improved development speed and confidence
Shipping reliably in a small team
Over time, our engineering team reduced from eight developers to two. At the same time, we inherited a system that was fragile and difficult to maintain.
Problem
The platform had frequent issues, a backlog of over 100 support tickets, and an architecture that made changes risky.
What I focused on
- Migrating to TypeScript to catch errors at compile time rather than in production
- Introducing Zod for dynamic runtime validation at system boundaries
- Adding Vitest tests alongside consistent linting and formatting across the codebase
- Overhauling CI pipelines so type checking, tests, and formatting ran on every change
- Simplifying architecture to reduce the surface area for bugs
Outcome
- Support backlog reduced from 100+ issues to typically fewer than 5
- Significant reduction in regressions — catching issues before they reached production
- Faster, more confident deployments with a reliable pipeline
- Better developer experience: clear feedback, consistent tooling, less firefighting
- Continued feature delivery despite the smaller team
What this changed
This experience shaped how I think about engineering: the right tooling and a small amount of upfront rigour pays back many times over in stability, speed, and developer confidence.
Bridging design and engineering
At Zoa I worked closely with two designers across a wide range of features including widgets, website re-designs, Shopify bundle implementation, subscription functionality and wishlists
Problem
With multiple features in flight simultaneously, design and engineering can easily drift apart. Patterns diverge, edge cases get missed until late in implementation, and visual inconsistency accumulates across a product that users experience as one thing.
What I did
- Implemented Figma designs faithfully across all of these features
- Raised UX concerns during implementation — interaction states, edge cases, and gaps not covered in designs
- Encouraged the team to build a design system to establish shared, reusable patterns
- Worked with designers to define component behaviour before development, not after
Why
Shipping quickly is easier when design and engineering share a vocabulary. A design system isn't just a Figma file — it means decisions get made once, reused everywhere, and stay consistent as the product grows.
Outcome
- More consistent UI across a broad and varied feature set
- UX issues caught earlier in the process, reducing rework
- Clearer handoff between design and engineering
- Shared patterns that made new features faster to design and build