What to put in a React Native development company RFP

A React Native development company RFP should state eight things: the feature list split into shared and per-platform work, the offline posture, the device and operating system matrix, every integration with its authentication model, who owns the store accounts and signing keys, acceptance thresholds expressed as numbers, the post-launch support expectation, and the commercial model you will sign.

Most mobile RFPs are a feature list and a deadline, which is why the bids that come back are not comparable and the quotes do not survive contact with the build. What follows is the document section by section, with the sentence to write in each and the specific thing a vague version will cost you later.

Why mobile RFPs go wrong more often than web ones

A web RFP can be vague about the runtime because you control it. A mobile RFP cannot, because two platform owners, an unknown fleet of handsets and an app review process sit between your requirements and your users. The cost drivers in a mobile build are mostly invisible in a feature list.

Three things in particular decide the price and almost never appear in the brief: how much of the app must work without a connection, how old the oldest supported device is, and how many external systems the app must authenticate against. A vendor who receives no answer to those either pads the quote or wins it and renegotiates in month two. Neither outcome helps you.

The purpose of the sections below is not bureaucracy. It is to remove the three or four unknowns that force every bidder to guess differently, so that the numbers you receive are answers to the same question.

The eight sections, and what a vague version costs

Section one: scope, split the way the work is actually done

Write the feature list, then mark each item shared or per-platform. Sign-in, catalogue browsing, forms and dashboards are shared. Biometric unlock, background location, push channels, deep links, document scanning, in-app purchase and accessibility semantics are per-platform, because they are implemented and tested twice regardless of the framework. This single column changes the shape of every bid you receive and gives you a basis for comparing them.

Include what is out of scope with the same care. A one-line exclusion, for example that the app will not support tablets in phase one, removes a whole class of layout and testing work and prevents a bidder from quietly including it.

Section two: the offline posture, decided before anyone estimates

Choose one of three answers and write it in the RFP. Online-only means the app shows an error without a connection. Read-offline means cached content remains readable but nothing can be edited. Full offline editing means users create and modify records that reconcile later, which requires client-generated identifiers, idempotency keys, version stamps and a written conflict rule for every editable entity.

The gap between the first and the third answer is weeks of backend work, so it belongs in the RFP rather than in a change request. The mechanics and the conflict cases are set out in offline-first mobile apps.

Section three: devices, and the ones you would rather forget

State the minimum iOS and Android versions you will support and name the three lowest-specification handsets that must pass acceptance. If your warehouse team uses a four-year-old Android device with two gigabytes of memory, that device is a requirement, not a detail. It determines list virtualisation, image handling, bundle size and sometimes the animation approach.

Add the target API level you must meet at launch, because Google Play enforces a minimum for new updates and a build below it cannot be published at all. That deadline is external and non-negotiable, which makes it exactly the kind of thing an RFP should carry.

Section four: integrations, with their authentication model

List every system the app will talk to, and for each one give three facts: the protocol or API style, the authentication model, and who owns the credentials. An OAuth 2.0 REST API with published documentation is an afternoon. An internal service behind a VPN with a bearer token issued by a team that meets on Thursdays is a fortnight. The feature description is identical in both cases, which is why bidders guess.

Payments deserve their own line. Physical goods and services route through your gateway; digital content and subscriptions consumed inside the app fall under store in-app purchase rules, and Apple sets out the conditions in its App Review Guidelines. Getting this wrong is not a cost overrun, it is a rejected release.

Section five: accounts, keys and code ownership

Require that the Apple Developer Program account, the Google Play Console account and the signing keys are held in your organisation's name from day one, with the vendor added as a user. This costs nothing at the start and is the difference between changing suppliers in a week and changing them in a quarter. The wider contract terms worth fixing early are covered in who owns the code, prompts and models.

Section six: acceptance thresholds as numbers

An acceptance criterion without a number is an opinion. Put four in the RFP and ask bidders to confirm they can meet them: a crash-free sessions rate measured over the first fortnight, a cold start time on your named low-end device, a sync completion time after a period offline, and a maximum bundle size. Numbers turn the final sign-off meeting from a negotiation into a measurement.

• Crash-free sessions. State the percentage and the measurement window, on both platforms.
• Cold start. A time in seconds, on the named low-end Android handset rather than a flagship.
• Sync completion. How long after reconnecting a full queue must be cleared.
• Bundle size. A ceiling for the download, which matters on metered connections.
• Accessibility. The conformance level expected, tested with the platform screen readers.
• Store readiness. A first submission to internal testing by a stated week, not at the end.

Section seven and eight: support and the commercial model

Say what happens after launch, because it changes who bids. Ask for response times, working hours and a stated cadence for framework, SDK and toolchain upgrades. Our own tiers 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 the full list is on the pricing page.

Then name the commercial model. Fixed price works when scope is genuinely locked, which is why we pair it with scope lock as a discipline rather than a hope. A React Native mobile application development engagement starts at $17,500 or ₹11.2 lakh and runs to $70,000 or ₹46.4 lakh where offline sync, payments and deep native integration are all present, and the cost breakdown post shows what moves a bid between those ends.

What not to put in the RFP

Leave out the architecture. Specifying the state management library, the navigation package or the local database in a procurement document narrows your field to vendors willing to agree with you and tells you nothing about their judgement. Ask instead for the reasoning behind their default choices and the conditions under which they would change them.

Leave out a deadline you invented. A date tied to a real event, a trade show, a regulatory change, a season, is useful information that bidders can plan around. A date chosen because it sounds decisive produces optimistic bids that fail quietly. If the date is genuinely fixed, say so and let scope flex instead.

When an RFP is the wrong instrument

If you cannot yet answer the offline question, name your integrations or describe the oldest supported device, an RFP will convert your uncertainty into a wide spread of bids you have no way to judge. A short paid discovery engagement that produces the scope, the device matrix and the integration inventory is a better first purchase, and the resulting document makes the eventual RFP worth running.

An RFP is also the wrong instrument when the real question is whether to build an app at all. If your users open the product twice a year, a responsive web application will beat a mobile app on both cost and adoption, and a serious vendor will tell you so before quoting.

Related reading

What a fixed-price quote should contain covers the response side of the same document, and App Store and Play Store submission lists the review requirements worth writing into acceptance criteria. If you would rather talk the scope through than write it twice, contact us.

A good mobile RFP is not longer than a bad one; it simply answers the four questions every bidder would otherwise have to guess.