How to measure whether React Native development company is working

Measure four things: crash-free sessions, cold start time on your cheapest supported device, release frequency including over-the-air updates, and completion rate on the app's one core journey. Those four React Native development company metrics tell you whether the app is stable, fast, shippable and useful. Everything else is supporting context.

This article separates delivery metrics from product metrics, gives you a target and a failure mode for each number, names the three measurements that reliably mislead, and sets out the release gates that turn metrics into something with teeth.

Delivery metrics and product metrics answer different questions

Delivery metrics tell you whether the engineering is sound: crashes, start-up time, build success, time from merge to store. A partner controls these directly, and they are the fair basis for judging React Native mobile development work.

Product metrics tell you whether the app was worth building: activation, retention, completion of the journey that justified the budget. A partner influences these but does not control them, because a beautifully engineered app for a job nobody needs done will still fail. Judging a build team on retention alone is as unfair as judging them on nothing.

The useful discipline is to hold delivery metrics as gates, meaning a release does not ship if they are red, and product metrics as direction, meaning they steer the next quarter's roadmap. Confusing the two produces either a team that ships fast and breaks things or a team that never ships at all.

What should we actually be tracking?

Track eight numbers. The table gives the healthy target, the instrument and the way each one lies to you if you read it alone.

Two of those deserve a note. Google Play measures user-perceived crash rate and application-not-responding rate as core vitals, publishes bad-behaviour thresholds for both, and reduces store visibility for apps that exceed them; the thresholds and measurement windows are documented at developer.android.com. Crash-free sessions is therefore not an engineering vanity number, it is a distribution risk, which we argue in crash-free sessions: the metric that predicts app reviews.

The other note is on device tiers. India-facing apps run on handsets that cost a tenth of the phone the app was built on, and every performance number should be read at that end of the fleet. A dashboard that averages across devices will show you a healthy app while a quarter of your users wait four seconds for a screen that opens instantly in the office.

The three measurements that mislead most often

• Story points delivered. They measure estimation consistency, not progress. A team can burn a hundred points a sprint and ship nothing to a user.
• Aggregate app store rating. It is a lagging average dominated by history. Track the rating of reviews left in the last thirty days instead; it moves when your app moves.
• Total downloads. Downloads are a marketing number. An app with 200,000 installs and 4,000 weekly active users has a product problem that the install chart conceals.
• Average session length. Longer is good in a content app and bad in a field-service app where the job is to record an inspection and get out. Decide the direction before you track it.
• Code coverage. Useful as a floor, useless as a target. Coverage rises fastest on the code that matters least.
• Velocity comparisons between teams. Points are not a currency. Comparing two teams' velocity mostly measures who estimates more generously.

Adoption after launch deserves its own treatment, and we set out how to measure it honestly in measuring adoption after go-live.

How much does instrumenting this cost?

Less than most teams expect, because the tools are commodity. Crash reporting, performance traces, product analytics and an over-the-air update channel are configuration work inside a React Native build, typically two to four days of engineering inside a programme that runs from $17,500 or ₹11,20,000 to $70,000 or ₹46,40,000. The starting figures are on the pricing page.

The recurring cost is attention, not money. Somebody has to read the dashboard weekly and act on it. That is what a Care Plan buys: Essential at $1,000 or ₹68,000 a month with business-hours cover, Standard at $2,500 or ₹1,60,000 with 24 by 5 cover and a four-hour response, or Enterprise at $5,250 or ₹3,40,000 with 24 by 7 cover, a one-hour response and a named engineer. The scope of that cover is described under maintenance and support.

One more line that is easy to forget: the cost of not measuring. A defect that reaches the whole fleet because nobody watched a staged rollout costs more in support hours and store reviews than a year of instrumentation, and store ratings recover far more slowly than crash graphs do.

Turning metrics into release gates

Pre-merge gate

Type checks, unit tests and a successful build for both platforms. No metric here is about users; the gate exists so that broken code never reaches a device. A React Native project without a working iOS build in continuous integration will discover its iOS problems at release, which is the most expensive moment to find them.

Pre-release gate

Cold start measured on the cheapest supported handset, crash-free sessions from the internal build track above target, and the core journey passing an automated end-to-end run on both platforms. If any is red, the release waits. Publishing this gate in writing changes vendor behaviour more than any clause in a contract.

Post-release watch

For 72 hours after a staged rollout, watch crash-free sessions and the not-responding rate by device model and OS version, not in aggregate. Roll back with a feature flag or a fresh over-the-air bundle rather than a store submission. The store review path is slow enough that it is not a rollback mechanism, as app store and play store submission explains.

When measurement is the wrong thing to focus on

Before your first release there is nothing to measure, and dashboards built in that period measure the team's activity rather than the product's health. Spend that time defining what the core journey is and what a completed one looks like in the event stream, so that on launch day the number exists.

Measurement is also wrong when it becomes the work. Teams that report eleven metrics weekly usually act on none of them. Pick four, put them on one page, and review them in fifteen minutes with a decision at the end. If a number has not changed a decision in two months, stop collecting it.

And be careful with any metric that a partner can improve without improving your product. Session length, screen views and downloads are all gameable. Completion rate on a journey you defined is not, which is why it belongs on the short list.

What this looks like in practice

For a last-mile logistics operator, the number that mattered was not crash-free sessions, though we held that gate anyway. It was the proportion of deliveries whose proof of delivery reached the back end within a shift, on handsets that spent hours without signal. That single measure told us whether the offline queue, the retry logic and the battery behaviour were all working together, and it is the kind of metric only the business can name. The system is described in the dispatch platform and driver app case study.

A measurement checklist before your next release

• Name the one core journey and the event that marks it complete
• Set the crash-free session target that blocks a release, in writing
• Identify the cheapest handset you support and measure cold start on it
• Confirm crash reports carry source maps so stack traces are readable
• Instrument the over-the-air update channel so you can see adoption by hour
• Split every dashboard by platform, OS version and device tier
• Agree who reads the numbers weekly and what authority they have to stop a release
• Write down which metrics you will deliberately ignore, and why

Related reading

React Native development company: a practical implementation guide covers the build practices behind these numbers, push notifications that users keep on deals with the one channel where a bad metric costs you the user permanently, and five ways React Native projects fail maps each failure to the measurement that would have caught it early.

A mobile app you cannot measure by device model is a mobile app you are not really operating.