The React Native Agency Shortlist: 11 Screening Questions, Our Own Answers, and How to Verify Each One

Why a screening rubric beats a shortlist of agency names

A rubric beats a directory because it forces every vendor to produce the same artifacts: live store listings, crash dashboards, upgrade commit history, and named engineers. Most "best React Native agencies" lists rank by who paid for placement or wrote the longest profile. Names change; evidence doesn't.

The eleven questions below are the ones we would ask if we were the buyer. Each one has three parts: what a strong answer contains, what a weak answer sounds like, and how to verify the claim without taking anyone's word for it. We have filled in our own answers so you can see what a complete response looks like, and so you can hold us to the same standard you hold everyone else to.

One structural note before you start. Ask these questions in a single written round, not spread across three calls. Agencies that improvise well on video calls tend to answer very differently in writing, and writing is what you will have to compare side by side.

Questions 1 to 4: production evidence, not portfolio screenshots

The first four questions establish whether an agency has shipped React Native apps real users depend on, or only prototypes and internal tools. The difference shows up in store standing, review volume, crash-free session rates, and whether anyone stayed on the codebase after launch. Ask for links, not slides.

Our answers, in the shape we would want yours. Q1, how many React Native apps do you have in production right now and where can I see them: four production engagements, all of which we will link to live store listings on request, including a consumer finance app with six-figure rating counts and seven-figure Android install counts, and a fitness community app rated above 4.8 on both stores. Q2, what is your crash-free session rate: we track it per release rather than as a lifetime average, because the number that matters is what happened in the 72 hours after each upgrade. Q3, how long have you stayed on a mobile codebase: our longest continuous engagement runs to six years, and mobile codebases in that portfolio have been with the same engineers for four years and counting. Q4, what did you ship from scratch and how fast: our last from-scratch build went from zero to both stores in 14 weeks.

Verification is straightforward and you should do it yourself. Open the store listings the agency names and check the developer field, the review count, and the update history. An agency that has genuinely maintained an app will have a visible cadence of releases, not a launch followed by silence. Ask for a screenshot of the crash dashboard filtered to a specific release window, not a lifetime figure, and ask which release had the worst number and why.

• • Q1: How many React Native apps do you have live in the stores today, with links?
• • Q2: What was the crash-free session rate before and after your last two React Native version upgrades?
• • Q3: What is the longest you have maintained a single mobile codebase, and is that team still on it?
• • Q4: Name one app you took from zero to both stores, and how many weeks it took.

Questions 5 to 8: engineering depth under the JavaScript layer

These four questions separate teams that assemble React Native apps from libraries from teams that can go below the JavaScript layer when a requirement demands it. Ask about native modules written, version upgrades survived, App Store rejections handled, and what they refuse to build. Vague answers predict expensive surprises.

Our answers. Q5, how many native modules have you written and why: a small number, deliberately. We write one only when no maintained community package covers the platform behaviour we need, typically around background behaviour, payment SDK surfaces, or device permissions the JS layer cannot reach cleanly. Every custom module is a maintenance liability at the next OS release, so the default answer is to find a maintained package first. Q6, how do you handle React Native upgrades: as scheduled work with a crash-rate gate, not as opportunistic maintenance. We upgrade behind a staged rollout and watch crash-free sessions per release before widening. Q7, how many App Store rejections have you had and what did each cost: we have taken rejections on from-scratch submissions, and the realistic cost is days, not hours, because you burn a review cycle after the fix. We budget for at least one rejection on any new build. Q8, what do you tell people to take elsewhere: heavy native AR and 3D graphics work, games, and apps that need a bespoke on-device ML runtime. React Native is the wrong starting point for all three, and we say so before a contract rather than after.

How to verify. Ask to see the upgrade commit history for a real project, even redacted, and read the pull request descriptions. Ask which specific React Native version broke the most for them and what the fix was; anyone who has done four upgrades has a story with a version number in it. For native modules, ask what the module does and what happens to it at the next major iOS release. For refusals, listen for whether the agency can name categories it declines. A vendor that says yes to everything has told you something.

• • Q5: How many custom native modules have you written, and what forced each one?
• • Q6: Walk me through your last React Native version upgrade, including what broke.
• • Q7: How many App Store rejections have you had, and how many days did each cost?
• • Q8: Name three kinds of mobile project you tell prospects to take to someone else.

Questions 9 to 11: who staffs it, what it costs, and how you contract

The final three questions are commercial and decide whether the engagement survives contact with your calendar and your lawyer. Ask exactly who will be on your project by name and seniority, what the rate bands are in your currency, and what contract vehicle they can sign in your jurisdiction. Refusal to answer in writing is disqualifying.

Our answers. Q9, who staffs a mobile engagement: we are a small senior team based in Osijek, Croatia. A mobile engagement is typically one to two React Native engineers plus a backend engineer where the app has its own services, with design pulled in as needed. There is no bench of juniors being rotated through, and the people on the pitch call are the people who write the code. Q10, what do you cost: we quote in EUR rate bands rather than a single blended number, and we publish how we set them in our Croatian agency comparison write-up. Q11, how do you contract: we work with UK, EU, and US clients on standard time-and-materials or fixed-scope agreements, with a DPA where personal data is in scope, and client-owned repositories from day one.

Time zones matter more than founders expect for mobile work, because store submissions, review responses, and crash spikes are time-sensitive. From Osijek we sit in CET, which gives a full working-day overlap with UK and EU clients and a usable afternoon window with US East Coast. Verify this by asking for the actual hours a vendor guarantees a response in your time zone, and by asking who is reachable when a production crash lands at 21:00 their time.

• • Q9: Name the specific engineers who will work on this and their seniority.
• • Q10: What are your rate bands in my currency, and what changes them?
• • Q11: What contract vehicle, DPA, and IP assignment terms can you sign for my jurisdiction?

What a weak answer sounds like, in the vendor's own words

Weak answers substitute volume for evidence, adjectives for numbers, and process for outcomes. "We've built over 50 mobile apps" with no live links, "we follow best practices for upgrades" with no version numbers, and "our team is highly experienced" with no names are the three most common. None of them can be checked.

A few specific red flags worth naming. An agency that cannot produce a crash dashboard has probably never operated an app at scale, because crash monitoring is the first thing you install and the last thing you remove. An agency whose portfolio apps have low review counts has built apps that shipped but were never adopted, which is a different skill from building apps that survive load. An agency that will not name its refusals will take your AR project and learn on your budget.

The inverse is also true and worth rewarding. When a vendor volunteers the release where their crash rate got worse, the rejection that cost them a week, or the feature they shipped and then removed, that is a team that measures its own work. You are buying their measurement habits as much as their code.

Running the rubric: a two-week process that fits a founder's calendar

Run the shortlist in two weeks, not two months. Week one: send all eleven questions in writing to four to six agencies with a five-day deadline. Week two: take calls only with vendors whose written answers contained checkable specifics, and spend those calls verifying rather than re-asking. Decide by the end of week two.

In practice the written round eliminates about half the list on its own, because agencies that cannot cite a live store listing tend not to reply at all. For the survivors, do the verification work yourself before the call: open the store listings, count the reviews, check the update cadence, and read any public repositories. Fifteen minutes of that gives you sharper questions than an hour of prepared agenda.

On the call, ask two things the written answers cannot cover. First, ask them to walk through a decision they got wrong on a mobile project and what it cost the client. Second, ask what they would need from you in the first two weeks, because a team that has done this before will ask for store credentials, analytics access, and a decision-maker rather than a specification document.

If you want to see the operational evidence behind our answers at full length, our React Native production write-up covers the upgrade log, crash rates, and store outcomes across four engagements.