KIERAN ARMBRECHT

Senior frontend developer, full-stack delivery

I ship production systems end to end. This is how I think through the harder calls.

Selected work

Three decisions, expanded.

Problem

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.

Options weighed

Add a cache layer · vertically scale the server · split into a dedicated microservice.

Decision

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.

Outcome

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

Problem

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.

Options weighed

A single flat permissions table vs. modelling access as separate, explicit layers.

Decision

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.

Outcome

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.

Problem

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.

Options weighed

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.

Decision

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.

Outcome

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.

About

I'm a senior frontend developer with 5+ years' commercial experience, working primarily in TypeScript, React and Vue, 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.

Contact

Email

···