Engineering
React that survives
the fifth team to touch it
We build React applications where the hard part was never rendering. It is state ownership, data freshness and keeping a 400-component tree navigable by an engineer who joined last Tuesday and needs to ship on Friday.
Overview
React front ends built for large teams, long lifespans and genuinely complex state.
Most React problems we are called in to fix are not React problems. They are unclear state ownership, a data layer that refetches on every keystroke, and a component tree grown past the point where anyone can predict a re-render. We begin by mapping those three things, then decide what genuinely needs rewriting and what only needs a boundary drawn around it.
Our default is React 19 with TypeScript in strict mode, TanStack Query for server state, and Zustand or plain context for the small amount of client state that deserves it. We keep that boundary explicit and enforce it in review, because teams that blur it are the ones still debugging cache staleness two years later.
Delivery happens in vertical slices: one working screen wired to real endpoints, with tests, telemetry and a keyboard pass, rather than a component library that meets no user for four months. Shared primitives and design tokens emerge from the second or third slice, once we can see what actually repeats.
- 1.9s to 0.7s
- Largest Contentful Paint on the Corvus Logistics dispatch board
- 38%
- Reduction in initial bundle size after route-level code splitting
- 3.4 days
- Median time from ticket start to production once CI gates were in place
Capabilities
What this covers
Six areas we staff properly. If your problem sits outside them, the honest note at the foot of this page says so.
State architecture and ownership
We decide which data belongs to the server cache, which belongs in the URL and which belongs to a component, then enforce that split in code review so it survives handover to your engineers.
Rendering performance work
Profiling with React DevTools and Chrome performance traces to find the real cost, usually a context provider re-rendering a list, then fixing it with memo boundaries, virtualisation and stable references.
Design system implementation
Accessible primitives built on Radix UI and Tailwind, shipped as a versioned package with Storybook documentation, visual regression baselines and a deprecation policy your product teams can plan against.
Server state and data fetching
TanStack Query configured deliberately: stale times set per resource, optimistic updates that roll back correctly, and request deduplication that holds up when a user hammers a filter panel.
Testing and CI budgets
Vitest and React Testing Library for behaviour, Playwright for the six journeys that must never break, and CI gates that fail the build when bundle size or interaction latency regresses past agreed limits.
Incremental legacy replacement
Screens migrated off jQuery, AngularJS or Backbone behind a routing shim, so old and new run side by side in one page and you can pause or stop the migration at any point without stranding users.
Deliverables
What you get
- React 19 and TypeScript source with strict mode on and no suppressed type errors
- Versioned component package with Storybook docs and visual regression baselines
- Unit, component and Playwright browser journey suites wired into your CI pipeline
- Performance budget configuration with bundle analysis and field Web Vitals reporting
- Architecture decision records covering state, routing and data-fetching choices
- Handover sessions plus a two-week pairing period with your in-house engineers
Stack
What we build it with
- React 19
- TypeScript
- Vite
- TanStack Query
- Zustand
- React Router
- Tailwind CSS
- Radix UI
- Storybook
- Vitest
- Playwright
- axe-core
Process
How the engagement runs
Two-week increments against a written definition of done. You can stop at any increment boundary and keep everything built so far.
Audit the code and the sessions
Two weeks reading the existing front end, profiling recorded production sessions and interviewing the engineers who maintain it, before we propose a single change.
Agree architecture and slice order
We fix state boundaries, routing shape and a sequence of vertical slices, each independently shippable, so nothing depends on a big-bang release date.
Deliver in fortnightly slices
Every iteration ends with a screen in staging against real data, reviewed for keyboard and screen reader use and covered by tests. No demo-only branches.
Harden under real data volumes
Profiling at production scale, fixing the re-render and payload problems that only appear with 10,000 rows, then locking the result in as a CI budget.
Hand the pen over
Your engineers take the next slice while we review rather than write. We leave once they have shipped two iterations without us touching the code.
When this is the wrong engagement
If you are building a mostly static marketing or content site, React is overhead paid on every page load, and a server-rendered or static setup will be faster for users and cheaper for you to run.
FAQ
Questions we get asked
- Do you work in our repository or start a new one?
Almost always yours. Full rewrites of a working front end fail more often than they succeed and stall feature delivery for months. We add the new architecture alongside existing code behind a routing shim, then retire screens one at a time.
- Which state library do you use?
TanStack Query for anything that came from a server, and Zustand for the genuinely local state left over, which is usually less than people expect. If your team already runs Redux Toolkit well, we work in that instead. Swapping a library your engineers know is rarely worth the disruption.
- Can you meet WCAG 2.2 AA?
Yes, when it is a requirement from the start rather than an audit at the end. We build on Radix primitives, run axe-core in CI and do keyboard and screen reader passes each slice. Retrofitting accessibility into a finished React application typically costs three to four times as much.
- How does handover to our team actually work?
We pair from the second iteration onward and hand over the keyboard before the engagement ends. The exit criterion is your engineers shipping two consecutive iterations with us only reviewing pull requests. The decision records explain why each choice was made, not just what it was.
Related
More in Engineering
Engineering
Blockchain Solutions
Permissioned ledgers, tokenised assets and independently audited smart contracts.
Engineering
IoT Development
Firmware, connectivity and telemetry pipelines for devices you cannot easily reach.
Engineering
Legacy Modernisation
COBOL, Delphi, WebForms and Oracle Forms moved off, without a big-bang cutover.