React.

Where React fits on a long engagement.

Most React work is not a new application. It is a codebase that has accumulated five years of components, three state-management approaches and a design system that stopped being authoritative some time ago. Useful work usually starts with deciding which of those to keep.

The decisions that age worst are state and data fetching. They are made early, they are invasive to change, and by the time they hurt they are everywhere. A specialist who will still be on the product in two years makes those choices differently from one delivering a milestone.

What an assigned team does with React.

A React codebase records every staffing decision ever made about it. Three state libraries means three eras of contractor; a component folder with four button variants means nobody stayed long enough to consolidate. Continuity is visible in the source, which is the argument for it that does not need making.

Feature work and platform work compete for the same capacity here, and the platform work always loses unless it is scoped separately. That is usually the point at which a partner moves from one specialist to outsource software development services covering both.

What we use React for.

• Consolidating a fragmented UI Several generations of components reduced to one set, so a change to a button stops meaning a change in nine places.
• Performance on real devices Render and bundle work driven by field data rather than a local machine with a fast connection.
• Design system implementation Components built to match a system a designer owns, with the two staying in step because both people stay on the account.

How React capacity is assigned.

React capacity is assigned under software development outsourcing, frequently next to design capacity so the component library and the design system are maintained by people who talk to each other. Capacity is agreed as a committed monthly capacity rather than per skill.