Senior frontend developer, full-stack delivery
I ship production systems end to end. This is how I think through the harder calls.
Five decisions, expanded.
A physical-retail product platform needed a redirect service so QR codes printed on in-store product labels could deep-link shoppers straight to the right product page. It also needed to survive real showroom scan volume, not just a demo load.
Add a cache layer · vertically scale the server · split into a dedicated microservice.
Redis first, on the same hardware. Measuring where request time actually went showed most of it was I/O wait on a database lookup, not CPU, so caching removed the real bottleneck for close to zero cost. Vertical scaling would have added more workers still blocked on the same I/O wait. A microservice would have traded a couple of milliseconds of latency for a second service to deploy, monitor and keep in sync, which wasn't justified by the actual load.
Modelled throughput went from roughly 60 to 400+ requests/second on the same server, with a clear, cheap next step to scale further only once it's actually needed.
~60 400+ req/s
~6.6× throughput, same hardware
An internal data-sync service — background jobs to keep textures, thumbnails, vectors, and catalog data in sync across systems — needed to be built from scratch, including a database migration system with rollback support. A related scene-management feature was built with full CRUD, but full write access to production scene data carried more operational risk than the feature actually needed.
Keep full CRUD in place vs. scope the feature back once the risk became clear.
Designed the sync service's architecture solo from the first commit — service layer, task-worker abstraction per job type, environment-aware migration rollback. On the scene-management feature, deliberately scoped a fully-built CRUD interface back to read-only with an environment selector once it was clear unrestricted write access wasn't worth the operational risk — treating "we already built it" as a weaker argument than "does production actually need this."
A sync service handling four job types in production, and a feature intentionally shipped with less capability than it was built with, because the smaller surface was the safer one to maintain.
Six client-branded builds run on the same shared internal engine, each maintained as its own fork. A UI improvement needed to land consistently across the fleet without each brand drifting into its own one-off implementation.
Reimplement the change independently per client vs. build it once and propagate it.
Converted an in-page save flow into a modal and extracted its notification logic into a reusable class, then manually rolled the same change out client by client across four branded builds in sequence — treating the fleet as one engine with brand-specific configuration, not four separate codebases to solve independently.
Consistent UX and shared, reusable notification logic across four brands within about six weeks, with no diverging implementations left to maintain going forward.
An embeddable product-visualizer widget needed to let integrators link or embed directly to one specific product, plus a public JavaScript API so host pages could read and control its state.
How strict to make SKU matching · how to resolve the target URL when embedded in a cross-origin iframe that can't read the parent page's address directly.
Matched on SKU, internal ID and product ID with an exact-match pass first, then a fuzzy fallback, so integrators didn't need pixel-perfect formatting. For the cross-origin iframe case, added an explicit fallback parameter rather than assuming access to the parent URL. Designed a two-part SKU syntax to address composite products without needing a second API.
A public API surface of 20+ methods and a deep-linking system that's now the documented integration path third parties use to link straight into a product.
A product platform needed to let different organisations independently manage which parts of a shared, multi-manufacturer catalogue they actually sell, spanning dozens of manufacturers and thousands of products, without one organisation's changes leaking into another's.
A single flat permissions table vs. modelling access as separate, explicit layers.
Split access into three concerns instead of one table: manufacturer-level access granted by an admin, range-level selection by the organisation and per-product opt-in with optional overrides. Kept "has access to a manufacturer" and "has chosen to sell a specific product" genuinely separate so neither could leak into the other. Migration was planned backward-compatible: old and new data written in parallel until the new structure was proven, then the legacy columns retired.
A schema that scaled to hundreds of product ranges and thousands of products across dozens of manufacturers without the permissions model collapsing into a tangle of special cases.
I'm a senior frontend developer with 5+ years' commercial experience, working primarily in TypeScript, Vue and React, with full-stack delivery in Node, Laravel and AWS. Day-to-day that now includes agentic AI tooling (Claude Code) built into my workflow for planning and implementation. I like being handed a hard, underspecified problem and figuring out the right shape for it. The case studies above are a better introduction to how I work than a skills list would be.
Based in North Devon, UK. Fully remote.