Senior Frontend Engineer · React · Next.js · TypeScript
I architect and optimize
web platforms that
hold up at scale.
7+ years across marketplace, media, and enterprise products — frontend architecture with full-stack range. I draw the boundaries first, prove the work with tests, and let a measurement pick the next optimization.
Frontend ArchitecturePerformanceDesign SystemsTesting & Release Safety
Impact overview
Outcome signals
Vendor dashboard architected
0→1Hobber · 7 modules, feature-sliced React + TS
Page load time
−15%Axinom · bundle, lazy-load & caching
Page load time
−40%Kodez · code-splitting across 40+ releases
Automated test coverage
~90%Kodez · Jest & Cypress — the suite gated in CI, not the number
Measured before/after against a defined baseline — not claimed causal.
—Impact
Numbers I can point to, stated conservatively.
0→1
Vendor platform architected from an empty repo — 7 feature-sliced modules · Hobber
Count
Authentication, vendor accounts, dashboards, scheduling, payouts, integrations and team access — shipped as independent feature slices over one shared component layer.
−40%
Page load time via code-splitting, lazy loading & asset optimization · Kodez
Before/after reading
A before/after read around the code-splitting and asset work.
Lab reading, not field data; one contribution among several.
~90%
Automated test coverage — Jest + Cypress, suite gated in CI · Kodez
Tool report
The overall number on the merged Kodez coverage report. The suite ran as a merge gate in CI — every critical path had to pass before a merge.
Not one column — branch sits lower. And the suite was gated, the number was not: a change that kept every test green while dropping the percentage would not have been stopped by CI.
−30%
Frontend dev time after the Storybook component library landed · Kodez
Estimate
My comparison of elapsed delivery on comparable screens before and after the library became the default way to build — at sprint granularity, in a team that was also growing.
Not an instrumented measurement, and I never published a before/after build time for a real screen — which is exactly the mistake the component spec records. Treat it as a judgement of roughly a third, not a figure.
250+
SQL tables in the schema behind the CMS I owned the frontend for
Count
The size of the schema the Kodez CMS was built against, across its enterprise integration surfaces.
The scale I worked against — I did not own the data model.
—Selected work
Four codebases, written as engineering decisions.
Tap or hover a case to open it
Hobber
MARKETPLACE PLATFORM · FRONTEND ARCHITECTURE
Architecting a vendor platform from an empty repo: feature slices over one sprawling dashboard.
Vendor dashboard architected 0→1Axinom
MEDIA PLATFORM · PERFORMANCE & DRM
Building on the platform instead of around it: Mosaic micro-frontends, Shaka Player DRM, and a ~15% faster load.
−15% page load · secure DRM playbackKodez
ENTERPRISE CMS · DESIGN SYSTEM & TDD
A CMS built to be changed: a Storybook design system, ~90% test coverage, and 40+ releases across three years, never a regression freeze.
−40% load · −30% dev time · ~90% coverage
RaSoft
INTERNAL SYSTEMS · 0-TO-1
Where the engineering habits started: owning an EMS end-to-end at a seed-stage startup.
EMS delivered 0→1 · +15% conversion—How I build
A repeatable engineering loop, not a bag of tricks.
01
Architect
Draw the boundaries before the first component.
I model the domains first — what owns what state, where the API surface sits, which pieces are genuinely shared. Feature slices with SOLID boundaries, so a new domain is a new folder instead of a refactor. This is the cheapest decision in the project and the most expensive one to reverse.
ADR · feature-slice map · component boundaries
02
Build
Compose from the system, don't author from scratch.
A screen should be assembled out of components that already exist and are already documented. TypeScript carries the contract between slices, Storybook holds the primitives, and server state stays separate from client state so data-fetching bugs don't turn into rendering bugs.
Storybook library · typed API layer · state model
03
Harden
Prove it, then ship it.
Tests are what make frequent releases safe rather than merely frequent. Test-first with Jest where the assertion shapes the design, Cypress on the paths a client would notice, both wired into CI/CD as a gate — plus cross-browser validation, because 'works on my machine' is a bug report waiting to be filed.
Cypress E2E · CI quality gates · BrowserStack matrix
04
Measure
Profile first, optimize second.
Every load-time win I can point to started from a measurement, not an instinct. Bundle analysis, code-splitting, lazy loading, caching — then measure again and report the before/after against a defined baseline rather than claiming causality.
Bundle audit · Core Web Vitals · before/after read
—Where I fit
Frontend architecture is my spine — and where it extends.
Architecture, performance, and design systems are the core I've shipped against. Full-stack delivery, testing discipline, and AI-native workflows are where that same instinct extends — each backed by a number, not just a title.
CoreHobberKodez
Frontend architecture
Feature-sliced structures with SOLID boundaries, so a codebase stays changeable after the third team joins it. Greenfield platforms, CMS builds organised as domain modules, and legacy surfaces migrated onto those boundaries screen by screen.
HobberKodezTwo platforms architected 0→1
CoreKodezAxinom
Performance engineering
Bundle analysis, code-splitting, lazy loading, and caching — always starting from a measurement rather than an instinct, and never reading the average alone.
KodezAxinom−40% and −15% page load
CoreKodez
Design systems
Component libraries documented in Storybook with an accessibility floor and a real promotion rule, so screens get composed instead of authored.
Kodez−30% frontend dev time
AdjacentKodezRaSoft
Full-stack delivery
Node.js BFF layers, ExpressJS services, and relational schema work — plus incremental migration off a legacy stack without freezing delivery.
KodezRaSoft250+ SQL tables · legacy stack retired incrementally
AdjacentKodez
Testing & release safety
Test-first with Jest, Cypress at the gate in CI, plus cross-browser validation — the reason releases stayed frequent and safe rather than merely fast.
Kodez~90% coverage · 40+ releases
Adjacent
AI-native engineering
Agent orchestration with sub-agent delegation, MCP integrations against real tooling, synthetic data for edge cases, and automated PR and CI/CD workflows.
Cross-company capability
Leverage on execution, not on judgment
—Contact
Open to Senior Frontend Engineer roles — onsite, remote, or relocation.
Get in touch.