React is a JavaScript library for building user interfaces out of reusable components. We use it for dashboards, portals and any screen a person spends hours in — anywhere the interface has enough state that rebuilding the page on every click would feel wrong.
What is React?
React is a library, not a framework, and that distinction matters when you are paying for it. It solves exactly one problem: keeping what is on screen in sync with the data behind it. Everything else — routing, data fetching, forms, server rendering — is a decision someone still has to make.
The core idea is components: a piece of interface and the logic that drives it, packaged together and reusable. A table row, a date picker, a whole checkout step. When the data changes, React works out the smallest set of DOM updates needed and applies them. You describe what the screen should look like; it handles getting there.
Meta built it and uses it at a scale nothing we build will approach, which is worth something: the hard performance edge cases have been found by someone else first.
When we choose React
We choose React when the screen has state — when what you see depends on what you have already done. A logistics control tower with live positions, a booking flow with dependent dropdowns, a dashboard with filters that combine. Those are miserable to build with page reloads and pleasant to build with components.
It is also the right call when the client has, or plans to have, in-house front-end developers. React has the largest hiring pool of any front-end technology by a wide margin, and in Dubai that is a practical advantage rather than a theoretical one: a stack you can hire for is a stack you can keep.
And when a mobile app is on the roadmap, React on the web makes React Native a much shorter conversation later — the mental model and a good deal of the logic carry over.
When we do not use React
We do not use bare React for a marketing site. A public page rendered entirely in the browser sends an empty shell to the crawler and to a customer on 4G, and both wait. For those we use Next.js, which is React with server rendering, or Laravel with Blade when hosting is constrained.
We also push back when React is proposed for a screen that is genuinely a form. A five-field contact form does not need a component tree and a build step; it needs a form. Reaching for React there adds a bundle, a build pipeline and a dependency-update obligation to solve a problem HTML solved decades ago.
And if the interface is mostly text — an article, a policy, a report — React is the wrong shape entirely. Content wants to be HTML.
What we build with React
Operations dashboards
The screen that replaces the spreadsheet the business is actually run from. Live data, filters that combine, exports finance can open, and role-based views so a driver, a dispatcher and a director each see the right thing. We built Meridian Freight's control tower this way — 300+ live consignments on one screen.
Customer portals
Where your customers check an order, download an invoice, book a slot or raise a ticket without phoning anyone. Usually sitting in front of an ERP or booking system you already run, talking to it over an API rather than replacing it — which keeps the project to weeks instead of the year a migration takes.
Multi-step flows that hold state
Applications, onboarding, quote builders, insurance forms. The value is in what happens between steps: validating early, saving progress so a dropped connection does not lose twenty minutes of typing, and showing a price that updates as choices are made.
Design systems your team reuses
When a business runs several products, we build the shared component library once — buttons, forms, tables, the lot — with the brand tokens baked in. Every subsequent screen is then faster to build and impossible to draw off-brand, which is the actual return on it.
How we ship React projects
Always TypeScript, never bare JavaScript. On a codebase anyone but the original author will touch, types are the cheapest documentation there is, and they catch the class of bug that only appears when a field is null in production.
Always inside a framework — Next.js for anything public, Vite for an internal tool. Bare React means hand-rolling routing and data fetching, and hand-rolled routing is where the accessibility bugs live.
Tests cover the logic that costs money if it is wrong: the price calculation, the permission check, the conflict when two people book the same slot. Not the button colour. Everything runs against a performance budget in CI, and a pull request that regresses it does not merge.
What React costs you
React ships JavaScript to the browser, and JavaScript is the most expensive thing you can send a phone: it has to be downloaded, parsed and executed before anything works. We budget for it explicitly, but a React screen will never be as fast to first paint as server-rendered HTML. That trade is worth it for a dashboard and is not worth it for a landing page.
The ecosystem also moves fast, and a React app left untouched for three years accumulates security advisories in its dependency tree. We budget an upgrade window every two years rather than discovering it at the point where an upgrade has become a rewrite.
Finally, React gives you nothing for free. Routing, forms, data fetching, accessibility — all decisions. Made badly, they are the actual source of most bad React applications, which is why we do not start from bare React.
React questions we get asked
Neither is better; they solve the same problem well. React has a much larger hiring pool, which usually decides it for a business that wants to bring development in-house eventually. Vue is quicker to learn if your team is coming from PHP or plain JavaScript. We ask who will maintain it in year two and pick accordingly.
Only if it is server-rendered. Google can execute JavaScript, but it does so on a delay and inconsistently, and other crawlers — including most AI crawlers — do not execute it at all. For anything public we build with Next.js so the HTML arrives complete. Bare React behind a login has no SEO requirement and is fine as-is.
Web applications start at $15,000 and typically land between $25,000 and $60,000 depending on the number of screens, how many roles need different views, and what it has to integrate with. The estimate comes back priced line by line so you can remove a screen rather than negotiate the total.
