What React development costs, and what moves the number

Almost every request for an estimate arrives as a screen count. Fourteen screens, a dashboard, a settings page. It is the most natural way to describe an application and one of the least useful ways to price one: we have built fourteen-screen products in five weeks and eleven-screen products in five months, and the difference had nothing to do with the screens.

What things actually cost

These are the bands we quote, at our own rates, for work we have done more than once. They assume a competent backend already exists or is being built alongside, and a client who reviews within a day.

The last row is honest rather than useless. When someone asks us to rebuild an existing application, the interface is a known quantity: it is on screen and it can be measured. What cannot be measured from the outside is what fifteen years of production data contains, and that is where the range comes from.

The four things that move the number

In order of how much they move it, and none of them are the thing most estimate requests describe.

Notice that three of these are backend or organisational realities showing up as frontend cost. That is the usual pattern and the reason "how much for the React work" is a hard question to answer honestly in isolation.

"Nobody has ever been surprised by how long the screens took. They are surprised by the permissions model and the data."

Two of those four sit on the backend rather than the interface, which is why a quote for React work alone is hard to give honestly. The backend side is scoped on the hire Node developers page.

The permissions trap, specifically

This deserves its own section because it is the single most common way a well-estimated project becomes a badly-estimated one, and because it is entirely avoidable at the start and nearly unavoidable later.

The pattern: the first version has two roles, admin and user, which is simple and correct for launch. Then a customer needs someone who can view invoices but not void them, and someone who manages one region, and a read-only auditor. Each addition looks small. Collectively they turn every list into a filtered list, every button into a conditional, every endpoint into an authorisation check, and every test into a matrix.

The advice that follows is not "build a full RBAC system on day one". It is narrower and cheaper: put the check in one place from the beginning, so that adding a role later is a data change rather than a search through every component.

A permission model added late is the clearest example of a cost that arrives long after the estimate. The same pattern, at the level of a whole engagement, is in what an offshore team really costs.

How to read an estimate

A number without assumptions is not an estimate, it is a negotiating position. What you want is a range and the list of things that would move it.

If the estimate is coming from an offshore vendor, the eleven questions that sort vendors covers what to ask before you believe the number.

How to genuinely reduce it

A performance target is worth agreeing at the same time as the scope, and setting a performance budget covers how to write one both sides can enforce.

What a scoping week actually produces

We keep recommending a paid scoping week, which is self-serving enough that it deserves a concrete description rather than an assertion. Here is what comes out of one, and what it costs relative to getting the estimate wrong.

1. 01

   Call the riskiest integration for real

   Not read its documentation — call it, with credentials, against a sandbox. Roughly half of integrations behave differently from their docs, and finding that out in week one costs a day instead of a month.

2. 02

   Profile the actual data

   Row counts, null rates, duplicates, orphans, encodings. Every migration estimate that goes badly wrong was written without someone looking at the real table.

3. 03

   List every role and exception

   One afternoon with whoever knows the business. This is the cheapest hour available anywhere on the project.

4. 04

   Write the scope as a document

   What is in, what is explicitly out, what is assumed. The out-list is the valuable half and the one usually missing.

5. 05

   Give a range with the risks named

   Narrow, with the two or three things that would move it stated plainly, so a change later is a conversation rather than a dispute.

Scoping is also how a paid pilot is priced: a fixed fee for a fixed fortnight, refunded if you do not continue.

Fixed price, time and materials, or capped

The commercial model changes the cost as much as the scope does, mostly by changing what each side is incentivised to argue about.

Our own default is time and materials with a written scope and a weekly burn figure, because it aligns the incentive on both sides towards finishing rather than towards arguing about what was agreed. For clients who genuinely need budget certainty, usually because the money is grant-funded or board-approved to a number, fixed price after a scoping week is the honest way to give it.

"Fixed price does not remove risk. It moves it to the vendor, who charges you for holding it, and then both of you spend the project arguing about what was in scope."

Whichever model you pick, the contract terms behind it are the same, and the contract checklist sets out what to agree before the first invoice.

Questions people ask

Where to go next

If a performance target is part of the scope, setting a performance budget a client will accept covers making it a contract term. If the framework choice is still open, React or Next.js has the cost implications. Our own engagement shapes are on the Node development services page.