Our React Reviews Took 4 Days and Caught Nothing — the 7 Quality Gates That Fixed It in a Month

The review queue was not the problem. The problem was that four days of review produced eleven comments about naming and zero comments about the re-render that took the search page down the following week.

Here are the seven gates we put in place, in the order we introduced them, and what each one is actually for.

Why review decays on a dedicated team specifically

Two causes compound, and neither is about the people.

Nobody wrote down what a review is for. So each reviewer applies a private standard, and comments drift toward whatever is easiest to see. Naming is easy to see. A subtle state placement bug is not. The review fills with cosmetic feedback and everyone feels productive.

The timezone gap multiplies every round trip. On a co-located team, four rounds of trivial comments cost an afternoon. On a dedicated team split across timezones, four rounds cost most of a week. The cosmetic comments are not just low value — they are expensive.

The fix is not more discipline. It is making the standard explicit and removing every judgement a machine can make from human hands.

Step 1 — Separate the machine gate from the human gate

Everything a machine can decide goes into continuous integration: formatting, lint rules, type checking, the test suite, a coverage floor and a bundle size budget. These either pass or block the merge. No human comments on them, ever again.

This is not primarily about speed. It is about removing the interpersonal cost of enforcement. A linter that rejects a formatting choice is a rule. A reviewer who rejects the same choice is a person making a judgement about another person’s work, and on a dedicated team with a client-vendor dynamic underneath it, that gets political fast — usually by everyone quietly agreeing to stop mentioning it.

Step 2 — Cap pull request size and mean it

Set a hard ceiling of roughly 400 changed lines, excluding lockfiles, generated code and snapshots.

Above that threshold, reviewers stop reading and start skimming. They approve because the alternative is two hours they do not have, and the approval is functionally meaningless. A 1,500-line pull request does not receive a stricter review than a 300-line one — it receives a worse one.

The critical part is the response when the cap is breached. An oversized pull request is a planning failure, not a heroic effort. Send it back to be split. On React teams the usual cause is a feature branch that also carried an opportunistic refactor, which is precisely the mixture that makes a diff impossible to reason about.

Step 3 — Write the four questions a React review must answer

Write them down. Put them in the pull request template. These four are mandatory; everything else a reviewer wants to say is optional commentary.

1. Where does this state live, and does it need to live there? Misplaced state is the root cause of most React re-render and synchronisation bugs. State lifted too high re-renders half the tree; state pushed too low gets duplicated and drifts out of sync.

2. What re-renders because of this change? The single most common production React problem we see is a context value or an inline object that silently causes a large subtree to re-render on every keystroke. It never fails in review because review happens on a diff, not on a running application.

3. Are the error and loading states handled? The happy path is always implemented. The failure path almost never is. Ask explicitly what this component shows while data is loading and what it shows when the request fails.

4. Is it reachable and operable by keyboard? Focus handling, keyboard reachability, and whether a div with an onClick is impersonating a button. Cheap to fix in review; expensive and embarrassing to fix after an accessibility audit.

Step 4 — Set a review latency service level

Agree a first-response time expressed in working hours — not calendar days — and measure it.

This matters disproportionately for a dedicated team in Singapore working with stakeholders elsewhere, or a Singapore-based team reviewing work produced overnight. If your reviewer’s working day starts after the author’s ends, every round trip costs twenty-four hours regardless of how fast anyone reads.

Two practical rules make the overlap work. Name a primary and a backup reviewer per area so nothing waits on one person’s calendar. And require that the first response is complete: all comments at once rather than trickled across three visits, because on a timezone gap a trickle turns a one-day review into a four-day one.

Step 5 — Type every comment as blocking, suggestion or question

Prefix each comment. Three types, nothing more:

• blocking: this must change before merge.
• suggestion: consider it, merge either way.
• question: I want to understand, not to change anything.

This costs one word per comment and removes an enormous amount of friction. A large share of review delay is authors trying to infer which comments actually stop a merge, and defensively addressing all of them — including the musings.

It matters more across a client-vendor relationship than within one team, because a dedicated team will treat every comment from the client as blocking unless told otherwise. That is a rational reading of the power dynamic, and it quietly doubles your cycle time.

Step 6 — Add a production evidence gate

Require the pull request to show that the behaviour works, not merely that the code compiles. A screenshot, a short screen recording, or a test that exercises the actual behaviour.

This is the gate that catches the largest class of React defects, because a diff cannot show you a rendering bug, a broken loading state or a component that works alone and breaks inside its real parent. Reviewing React from the diff alone is reviewing a description of the thing rather than the thing.

Keep the requirement proportionate: a screenshot for a visual change, a recording for an interaction, a test for logic. The point is that somebody ran it.

Step 7 — Review the gates monthly against real incidents

Once a month, list what reached production and caused a problem, then ask a single question of each item: which gate should have caught this, and why did it not?

Sometimes the answer is that no gate covered it, and you add one. More often the answer is that a gate exists but is unenforced, or that the review is drowning in cosmetic comments and the real question got lost. That is a signal to remove rules, not add them.

The failure mode to avoid is a review checklist that only ever grows. A twenty-item checklist is not applied — it is skimmed and signed. Keep the mandatory human list at four questions and let the machine gate absorb everything else.

What actually changes, and how fast

Expect the machine gate and the size cap to change cycle time within about two weeks — those are mechanical. The four questions take longer to bite, roughly a month, because reviewers need to build the habit of asking about state placement instead of naming.

The honest caveat: none of this compensates for the wrong team. Gates raise the floor and make standards portable when people rotate, which is exactly what a dedicated engagement needs. They do not turn engineers who have never debugged a production re-render into engineers who have. That part is a hiring question — the same one we work through when hiring developers into a growing team, and when structuring a dedicated React team in Singapore from the start.

One regional note: the React talent pool Singapore employers draw on increasingly overlaps with the Gulf, where the same engineers are being recruited for financial and government platform work. We see it in our own pipelines against engineering hiring in Dubai, and it is one reason retention on a well-run dedicated team is worth more than a marginally cheaper rate card.

Frequently asked questions