React is easy to start and expensive to maintain badly. Most of the React work we are called in to rescue is not slow because of React — it is slow because nobody drew a line between what a component owns and what it borrows.
Where the boundaries go
We decide early which components hold state, which only render it, and which are allowed to fetch. That single decision is what keeps a screen understandable after twenty people have touched it. Everything else — folder shape, naming, which library won this year’s argument — is a detail underneath it.
State that stays boring
Server data belongs in a cache with an explicit invalidation rule. UI state belongs close to the element that owns it. Global state is for the handful of things that genuinely are global: session, theme, feature flags. Projects get into trouble when those three categories are treated as one.
Performance is a budget, not a rescue
- A measured render budget per screen, checked in CI, not after launch
- Lists virtualised only when the numbers say so
- Bundle splits along routes people actually visit
- Images and fonts handled once, in the layout, not per page
The accessibility floor
Keyboard reachability, focus order and visible focus are part of the component review, not a later audit. A modal that traps focus correctly costs an hour when it is written and a fortnight when it is retrofitted.
When React is the wrong answer
If the page is text and images that change weekly, a React app is overhead you will pay for forever. That work goes to Astro instead. If the product needs server rendering and route-level data, we reach for Next.js. We say which one we would pick before the contract, not after.
Every component we ship is typed — see TypeScript — and styled through the token layer described under Tailwind CSS. The wider picture is on web development and the rest of the technology map.