Experience Engineering
Front ends that are still fast on the tenth sprint
The interface is where every system behind it gets judged. We build web and mobile front ends with an enforced performance budget, a design system somebody owns and WCAG 2.2 AA checked in CI — not audited after launch.
Engagement at a glance
- Capabilities
- 05
- Deliverables
- 08 artefacts
- Stack groups
- 04
- Ways to start
- 03
Engagement options
- Front-end audit2–3 weeks
- Design system build8–12 weeks
- Product build or replatform12–24 weeks
What breaks
The failure modes we keep meeting
Cheap to design around at the start. Expensive to discover once the system is carrying real traffic.
No budget, so every sprint adds 200KB
Nobody owns the byte budget, so nobody breaks it — they only add to it. A date library here, an animation runtime there, a tag manager that lets marketing ship an unreviewed script into production. Each change is defensible. Eighteen months later the checkout route ships over a megabyte of JavaScript and a mid-range Android takes nine seconds to respond.
A component library nobody owns
Three date pickers, two modal implementations, four shades of the same disabled grey. The Figma library drifted from the code six months ago and nobody can say which one is authoritative. Every new screen restarts the argument, and every fix has to land in three places — or, more honestly, in one.
Accessibility bolted on at audit time
A procurement team asks for a VPAT and the custom combobox turns out to be a keyboard trap. Focus is lost on every client-side route change. The primary call to action fails contrast. None of this is hard to build correctly the first time; all of it is expensive to retrofit under a deadline.
Capabilities
What the work actually consists of
01
Design system and tokens
A component library with an owner, a version number and a deprecation policy. Tokens are the contract: one source of truth that compiles to CSS custom properties, a Tailwind theme and native equivalents — so a brand change becomes a release rather than a migration.
- Token pipeline from Figma Variables through Style Dictionary to CSS, Tailwind and the native platforms
- Primitive layer on Radix UI or React Aria so keyboard and ARIA behaviour is inherited, not reimplemented
- Storybook as the contract surface, with visual regression and interaction tests running on every pull request
- Light and dark as first-class token sets, plus forced-colors and prefers-reduced-motion handling
- Semantic versioning, codemods and a written deprecation policy so consumers upgrade without a feature freeze
02
Application architecture
Next.js App Router work that takes the server seriously — deciding what renders on the server, what streams, what is cached and for how long. Most front-end performance problems are architecture problems wearing a bundle-size costume.
- Server and client boundary design: what stays a Server Component, what genuinely needs “use client”, and why
- Caching strategy across the data cache, route segments and the CDN, with explicit revalidation rules per route
- Suspense and streaming boundaries placed where they cut perceived latency, not where they are easiest to add
- Data layer: server actions, TanStack Query on the client, optimistic updates with a rollback path that works
- A rendering decision recorded per route — static, incremental, dynamic — so the next team inherits the reasoning
03
Performance engineering
Budgets first, then measurement, then the work. A budget that fails a pull request is the only kind that survives contact with a delivery date — everything else is a dashboard nobody opens after the second month.
- Per-route JavaScript, CSS and image budgets enforced in CI with size-limit and Lighthouse CI
- Field RUM using the web-vitals library: LCP, INP and CLS at p75, segmented by device class, network and route
- INP work — breaking up long tasks, yielding, virtualising lists, and deleting hydration that earns nothing
- Image, font and third-party discipline: self-hosted fonts, priority hints, and a review gate on tag manager scripts
- Diagnosis from Chrome DevTools traces and WebPageTest filmstrips rather than guessing from a single score
04
Accessibility and internationalisation
WCAG 2.2 AA treated as an engineering requirement with tests attached, not a document produced at the end. Automated rules catch the shallow half; keyboard paths, screen-reader semantics and focus management are the rest.
- axe-core assertions inside unit and Playwright tests, plus Pa11y CI on key routes, gating the build
- Manual passes with NVDA, VoiceOver and keyboard only, written up as reproducible scripts anyone can rerun
- Focus management across route changes, dialogs and live regions — precisely the part an overlay cannot fix
- ICU message formatting through next-intl or FormatJS, with plurals, dates and RTL layout under test
- Locale-aware typography, number and address formats, and a translation workflow that is not a spreadsheet
05
Mobile, offline and experimentation
One team, both surfaces. React Native with the New Architecture where code sharing genuinely pays, native Swift or Kotlin where it does not — and offline treated as a normal state rather than an error screen.
- Expo and React Native on the New Architecture (Fabric, TurboModules) with EAS builds and OTA update channels
- Native modules in Swift or Kotlin when the platform API, or the frame budget, demands it
- Offline-first data with a local SQLite store, a queued mutation log and conflict rules somebody can explain
- Progressive enhancement and service workers so a flaky network degrades the page instead of blanking it
- Flags and experiments behind OpenFeature, with guardrail metrics so a winning variant cannot quietly cost 300ms
Outcomes
Targets, and where each number comes from
The basis line under every figure is the point of this section. Where a number is a design standard rather than a measured delivery, it says so — we would rather be checkable than impressive.
- Largest Contentful Paint at p75 on mid-range mobile
- ≤ 2.5sLargest Contentful Paint at p75 on mid-range mobileGoogle’s published ‘good’ threshold for Core Web Vitals, tracked as a field target in RUM and backed in CI by a throttled mid-range mobile lab assertion on the same routes.
- Interaction to Next Paint at p75
- ≤ 200msInteraction to Next Paint at p75Chrome’s ‘good’ INP threshold, measured from field RUM on real devices — not a lab run on an engineer’s laptop.
- axe-core violations on the audited journeys at release
- 0 seriousaxe-core violations on the audited journeys at releaseRelease gate on the flows in scope. Automated rules cannot certify a whole product; the manual keyboard and screen-reader passes carry the remainder.
- One canonical button, field, modal and date picker across the estate
- 1 of eachOne canonical button, field, modal and date picker across the estateDesign target for a design-system engagement, verified by counting implementations in your repository before and after.
Stack
What we reach for, and when
Defaults, not dogma. The list below is what we would propose on a blank page; an existing estate, a procurement constraint or a team's operating experience all legitimately move it.
- Next.js 16 App Router
- React 19
- TypeScript 5.x
- React Router 7
- Astro
- Vite
- Node.js 22 LTS
- Tailwind CSS v4
- Radix UI primitives
- React Aria Components
- Style Dictionary
- Figma Variables / Tokens Studio
- Storybook
- Container queries and cascade layers
- Expo / React Native New Architecture
- SwiftUI
- Jetpack Compose
- Workbox service workers
- SQLite / op-sqlite
- EAS Build and Update
- Vercel, Cloudflare or CloudFront
- web-vitals RUM
- Lighthouse CI
- size-limit
- Playwright
- Vitest and Testing Library
- axe-core / Pa11y CI
- NVDA, VoiceOver, JAWS
- next-intl / FormatJS ICU
- OpenFeature with GrowthBook or Statsig
- PostHog
- Sentry and OpenTelemetry browser tracing
Deliverables
What you keep
Everything below lands in your repositories and your accounts, under your licence, with the reasoning written down. There is no runtime you have to keep renting from us.
08 artefacts, handed over
- Versioned design-system package — tokens, primitives, themes — with a published Storybook and an owner named in writing
- Per-route performance budget wired into CI, so a regression turns the pull request red before review
- Core Web Vitals RUM dashboard segmented by device class, network and route, with alerting on p75 drift
- WCAG 2.2 AA conformance report with reproducible test scripts and the remaining gaps stated plainly
- Front-end architecture document: rendering strategy per route, caching and revalidation rules, server and client boundary
- Playwright suite covering the critical journeys, including keyboard-only and screen-reader-visible paths
- Internationalisation setup with ICU messages, RTL support and a translation handoff that does not involve email
- Release runbook: preview environments, flag rollout, OTA update policy and a rehearsed rollback
Engagements
Three honest ways to start
Sized so the first one can end. Each option is designed to produce something usable even if we never work together again.
Front-end audit
2–3 weeks
The interface feels slow and the Lighthouse score insists it is not. You need to know which it is before committing a quarter.
Includes
- Field RUM instrumented on day one and two weeks of real-user data collected
- Bundle, trace and render-path analysis on the three highest-traffic routes
- WCAG 2.2 AA gap assessment on the primary journey, with severity and effort per finding
- Prioritised backlog: expected effect on p75, estimated effort, and what we would not bother fixing
Design system build
8–12 weeks
Several teams, several button components, and a Figma library nobody trusts. Consistency has become a standing tax on delivery.
Includes
- Token architecture from Figma through Style Dictionary to web and native outputs
- Accessible primitive layer plus the first twenty to thirty production components
- Storybook, visual regression and interaction tests running in CI
- Migration of two real product surfaces onto the system, with codemods and an adoption guide
Product build or replatform
12–24 weeks
A web or mobile surface to build properly the first time — or an ageing one to move route by route, without a big-bang rewrite.
Includes
- Architecture, rendering and caching decisions documented before the first component is written
- Incremental migration under flags, with old and new routes serving side by side
- Performance, accessibility and internationalisation gates active from the first merge
- Mobile surface in React Native or native, sharing the token layer with the web
- Handover: runbooks, dashboards and two review cycles run jointly with your engineers
Questions
The awkward ones
The questions that decide whether this is worth starting — answered the way we would answer them on a call.
Lighthouse is a lab test: simulated device, cold cache, no third-party tags, no session history. Real users arrive mid-session on a four-year-old Android with a tag manager, a chat widget and an ad blocker fighting each other. Field data usually tells a different story — and INP, which measures how long an interaction takes to actually paint, is a field metric that a lab run does not report at all.
Adjacent work
These are the practices this one leans on and the reference architectures that show it assembled.
Related solutions
Reference architectures
Next step
Bring us the problem you keep deferring.
A 45-minute working session on your Experience Engineering work. We will tell you what we would build, what we would not build, and roughly what it costs. No deck.