Questions to ask a React Native development company vendor before you sign

Ask a React Native development company vendor five things before you sign: show me an app you shipped and its live store listing, who on this team writes native code, what is your offline and sync approach, which numbers define done, and what happens on the day we leave. Vendors who have shipped answer all five in minutes.

Below are the questions grouped by the stage at which they are worth asking, each with the answer that indicates experience and the answer that should slow you down. They are written to be asked out loud, in a call, where hesitation is as informative as content.

The question that does most of the work

Start with this: name an app you built that is in the App Store and Google Play today, and tell me which parts your team wrote. Then open it on your own phone during the call.

It is a simple request and it eliminates a surprising share of the field. Some vendors will describe work under an NDA, which is legitimate, but they should still be able to name the category, the integrations, the offline behaviour and the release cadence. What you are testing is not confidentiality; it is whether anyone in the room has been through store review, staged rollouts and a bad release week.

Follow with the second half of the same question: show me a commit in a native module. React Native is a JavaScript surface over two native platforms, and every serious project eventually needs Swift or Kotlin, whether for an unmaintained library, a device-specific crash or a performance problem the profiler will not explain from JavaScript.

What a strong answer sounds like

Round one: capability, asked on the first call

These questions establish whether the vendor understands mobile as distinct from web. Ask them early, because a weak answer here makes everything later irrelevant.

• What did the last store rejection you received say? Everyone who ships has had one. A vendor who claims never to have been rejected has either not shipped or is not telling you the truth.
• Which parts of a React Native app do you write twice? The answer should include permissions, background work, push, deep links, biometrics, payment sheets and accessibility semantics.
• How do you decide between React Native and native? Look for conditions, not loyalty. Sustained camera work, low-latency audio and complex Bluetooth all point away from a shared codebase.
• What is in your standard first sprint? Instrumentation, crash reporting and a skeleton store submission belong there, not in the final month.
• How do you test on real hardware? Ask for the device list, and check that it contains an ageing low-specification Android handset.
• What conformance level do you design to? Accessibility is a procurement requirement in more markets every year, and the reference is the W3C's Web Content Accessibility Guidelines adapted to platform screen readers.

Round two: delivery and risk, asked on the shortlist call

By this stage the vendor has seen your requirements, so the questions move from general competence to your specific project. The best signal is whether they push back on anything.

Ask what in your brief they think is wrong, expensive or premature. A vendor who agrees with every line of a requirements document has either not read it or has decided that disagreeing costs them the deal. We would rather lose a bid than start one with a scope we believe is unbuildable in the time available, and we say so in the first call.

Ask how they would handle the offline question for your users specifically. The right response is another question, about where and how your users work, because the answer changes the API contract rather than a library choice. The three postures and their consequences are set out in what to put in a React Native RFP.

Ask who the named engineers are and what else they are assigned to during your build. Agency staffing that moves people between accounts mid-project is the most common cause of a delivery that starts well and drifts, and it is visible in advance if you ask for names rather than roles.

Round three: commercial, ownership and exit

These are the questions people postpone until contract review, by which point the leverage has moved. Ask them while you are still comparing bids.

Who holds the Apple Developer Program account, the Google Play Console account and the signing keys? The correct answer is your organisation, from the first day, with the vendor added as a user. A vendor holding your keys is not malice; it is simply a dependency that costs you a quarter on the day you want to change supplier. The wider set of clauses worth fixing early is in who owns the code, prompts and models, and the principle is summarised in our code and IP ownership definition.

What does year two cost? A build price without a running cost is half an answer. Ask for the support tier, the upgrade cadence and the hourly rate for work outside the plan. Our own care plans run from $1,000 or ₹68,000 a month for business-hours cover to $5,250 or ₹3,40,000 a month for 24 by 7 with a named engineer, and everything is listed on the pricing page.

What does handover contain? Ask for the specific artefacts: repository access, build and release documentation, the device matrix, the architecture decision record, environment configuration and credentials, and a working walkthrough with your engineers. We treat this as a deliverable rather than a courtesy, and the reverse case, inheriting someone else's system, is described in taking over a system you didn't build.

Finally, ask how escalation works when something breaks at nine in the evening. You want a named person, a channel, a response time and a stated definition of severity one, not an assurance that the team is responsive. Mobile incidents are unusual in that the fix cannot always be deployed immediately: a critical defect may need a new build, a new review and a staged rollout, so the escalation answer should include how the vendor limits damage while the release is in flight.

Questions that sound rigorous but tell you nothing

Some standard procurement questions produce no signal in a mobile context. How many developers do you have measures the agency, not the team you will get. Are you certified in a given methodology tells you about process documentation rather than shipped software. Which state management library do you use invites the answer the vendor thinks you want to hear.

Replace each with a question that has a factual answer. Instead of team size, ask who is named on your statement of work. Instead of methodology, ask what happened on their last project that slipped and what changed afterwards. Instead of library preferences, ask for the reasoning behind a default and the condition that would change it.

When this process is the wrong use of your time

If you cannot yet say what the app is for, who opens it and what it must do without a connection, vendor diligence will not rescue the decision. Every bidder will fill your gaps with different assumptions and you will end up choosing on price. A short scoping engagement that produces the feature split, the device matrix and the integration inventory is the better first purchase.

It is also the wrong process if the honest answer is that you do not need an app. Occasional usage with no offline requirement and no device integration is better served by a responsive web application, and a vendor who takes that brief without challenging it has told you something about how the rest of the engagement will go. The trade-offs are in React Native vs Flutter vs native.

How we answer these ourselves

We publish our prices, so the commercial questions are answered before the call: React Native mobile application development starts at $17,500 or ₹11.2 lakh and runs to $70,000 or ₹46.4 lakh depending on offline sync, payments and integration depth. You own the code, the infrastructure and the accounts from the first commit. Our dispatch platform and driver app is the offline-first work we point at when someone asks the sync question, and a call through contact is usually faster than a questionnaire.

Related reading

How to choose a development company covers the general diligence checklist, and crash-free sessions explains the single number worth writing into your acceptance criteria.

The questions that separate vendors are the ones with factual answers, because experience is easy to describe and hard to invent.