What we build with it
React is the most common front end we inherit. Our work in it is usually on applications that already exist: adding features, untangling state that has spread across contexts and effects, replacing data fetching that refetches more than it should, and fixing renders that got expensive as the app grew.
The library itself is small — components and hooks — and almost everything else is a choice the previous team made. Reading a React codebase is largely reading those choices: which router, which data layer, which state management, and whether they still agree with each other.
Where it fits
Existing product front ends and admin interfaces, and the web half of products whose mobile app we build in Flutter. Working across both is useful precisely because the same API has to serve them.
When we recommend it
When it is already there, or when a team is hiring against it — the pool of React developers is the largest of any front-end ecosystem, and that is a legitimate reason to choose it.
For a new project we would reach for Vue, or Nuxt when server rendering and SEO matter, because that is where our team is deepest. And if the question is mobile rather than web, we would compare properly rather than assume — we wrote up Flutter versus React Native for exactly that decision.
