Code Review Standards for React Native Agencies

Key facts, with sources

• In the US, junior React Native developers charge about $55 to $65 per hour, mid-level $65 to $90, and senior developers $95 to $180 per hour in 2025. (ReactSquad)
• On Upwork, React Native developer hourly rates typically range between $24 and $45, with a median around $30 per hour. (Upwork)
• React Native specialists command 15 to 35% rate premiums over standard React web developers, and agencies typically add a further 30 to 50% premium over freelancer rates. (Index.dev)
• Freelance React rates on major platforms average $51 to $75 per hour with a median of $63 per hour based on 2025 marketplace data. (Arc.dev)
• US React Native salaries in 2025 run from about $75,000 for juniors to $115,000 for mid-level and $155,000 or more for senior developers, a benchmark for comparing full-time versus consulting costs. (NextNative)

Automate the bottom layer or drown

No human should ever comment on formatting, import order, or a missing hook dependency — that is machine work, and every minute spent on it is a minute not spent on design. The baseline: TypeScript in strict mode, ESLint with the React Native community config plus hook rules escalated to errors, formatting enforced on commit, and CI that blocks merge on any of it failing.

The rule that pays for itself most in agency codebases is banning unstable nested components — components defined inline during render — because it silently destroys list performance and juniors reinvent it weekly. Once machines hold this layer, human review gets dramatically shorter and dramatically more useful.

// .eslintrc.js
module.exports = {
  root: true,
  extends: ['@react-native', 'plugin:@typescript-eslint/recommended'],
  rules: {
    'react-hooks/exhaustive-deps': 'error',
    'react/no-unstable-nested-components': ['error', { allowAsProps: false }],
    '@typescript-eslint/no-explicit-any': 'error',
  },
};

What human reviewers should actually look for

With the mechanical layer automated, human review targets judgment calls. State placement first: is this server state that belongs in the query cache, or client state — and is it held at the lowest component level that works? Effect misuse second: useEffect computing derived state, chained effects triggering each other, and fetch-in-effect patterns that a data library already solves are the most common structural rot I find in agency code.

Then the product-quality layer: are error, loading, and empty states handled, or does this screen assume the happy path? Are navigation params typed rather than passed as trusting blobs? Reviewers should be reading for "what happens when this fails on a bad network," because that is what the client's users will actually experience.

Performance rules worth enforcing in review

A handful of review rules prevent most of the performance complaints that reach clients. Lists get scrutiny by default: stable renderItem references, a proper keyExtractor, memoized row components, and no anonymous functions or object literals created per row. Images must be sized to their display dimensions and cached deliberately, not loaded at full resolution into a thumbnail. Animations belong on the UI thread via the standard animation library, and any animation driven by JavaScript state per-frame should be challenged in review.

Equally important is the counter-rule: no reflexive memoization everywhere. Wrapping everything in memo and useMemo without a measured reason adds noise and its own overhead. The standard should demand memoization where lists and profiling justify it, and clean code elsewhere.

Native changes get a different review lane

The diffs that break release week are rarely in TypeScript. Changes to the android and ios directories, Gradle and Podfile modifications, new permissions in the manifest or Info.plist, config plugin changes, and any new patch-package entry deserve a separate, stricter lane: they require a written explanation of why the change is needed and sign-off from a designated senior with native experience.

Permissions deserve special paranoia because they are user-visible and store-review-visible — an unexplained new permission can trigger rejection or user distrust. And every patch-package addition must carry a comment explaining what it patches and the upstream issue it tracks, because undocumented patches are the single most common upgrade blocker I find in agency-built apps.

Pull request mechanics for agencies

Standards die without mechanics. Cap PR size at something a reviewer can genuinely hold in their head — as a working rule, if it takes more than about thirty minutes to review properly, it should have been split. Require a description template: what changed, why, how it was tested, and a screen recording for anything visual, because UI review from code alone is guesswork. Set a review SLA so PRs never age into merge-by-exhaustion.

For client-facing polish, roll review outcomes into a short quality summary per milestone — what was reviewed, what was caught, what standards held. Clients rarely read the code, but they notice an agency that can show its quality process, and it justifies the rate.

When to hire senior help

Consulting help makes sense when your team is strong on web React but has never shipped to the app stores, when a delivery has stalled, or when you need a second opinion before a costly architectural commitment. Scope the first engagement small, an audit or a bounded feature, so both sides can verify fit before committing to months of budget. If your stack includes React Native + Python + AI, a senior engineer who owns the full product beats coordinating multiple juniors.

Bottom line

Dhairya Senjaliya ships Mobile — React Native Consulting projects worldwide — book a scoping call to discuss your specific situation.

Common pitfalls to avoid

• ✕Selecting purely on lowest hourly rate and paying twice when the rework bill from a $25-per-hour build exceeds the original quote
• ✕Signing fixed-bid contracts with vague scope and no acceptance criteria, guaranteeing disputes over what counts as done
• ✕Leaving the repository, signing keys, and store accounts under the contractor's ownership with no handoff clause in the contract
• ✕Committing to a months-long engagement without a small paid trial task or a review of the consultant's actual shipped store apps

Frequently asked questions

Sources

• ReactSquad
• Upwork
• Index.dev
• Arc.dev
• NextNative