The hidden costs of React Native development company that quotes leave out

The hidden costs of a React Native development company are almost all recurring. A build quote prices the first release, while platform and tooling subscriptions, a device lab, release operations, the annual framework and SDK upgrade cycle, and post-launch support continue for every year the app stays in the stores. They are predictable, and none of them is usually in the proposal.

This article is written as a ledger rather than an argument. Each line below states what the cost is, when it lands, who normally ends up paying it, and how to size it before you sign, using our own published figures where a number is needed.

Why mobile hides costs that web projects do not

A web application you have built is a web application you can change. Nothing outside your organisation forces you to touch it, so an untouched product can sit still for two years and still deploy.

A mobile app cannot. It lives inside two platforms whose owners publish annual deadlines, on devices whose operating systems update themselves, distributed through a review process you do not control. That is why mobile has a maintenance floor: the minimum spend required to keep a working app working, even in a year when you add no features at all.

Recognising that floor is what separates a total cost of ownership figure from a build price, and it is the number worth calculating before you choose a vendor rather than after. The general framing sits in our total cost of ownership definition.

The five lines quotes leave out

Line one: the subscriptions nobody itemises

An app in production is not free to keep in production. There is an annual Apple Developer Program membership and a one-off Google Play Console registration, and neither is normally in a development quote because it belongs to your accounts rather than the vendor's. Then come the services the app depends on: crash reporting, product analytics, a push notification provider, a build and distribution service, a feature flag tool, and occasionally a mapping or identity SDK with usage-based pricing.

Individually these are small. Together they form a monthly bill that arrives regardless of whether anyone is developing anything, and they usually land on a budget line nobody assigned. Write the list during procurement, with the owner and the renewal date beside each entry.

One test is useful here. Ask the vendor which of these accounts will be created in your organisation's name and which in theirs. Anything created in theirs is a cost you will pay twice: once now, and again as migration work on the day you change supplier or bring the app in house.

Line two: devices you do not own yet

Simulators do not catch the defects that matter. Aggressive background process killing on some Android manufacturers, notification behaviour that differs by vendor skin, camera and storage permission flows that vary by version, keyboard behaviour on older handsets: all of these appear only on hardware.

The cost is not large but it is real, and it is always discovered late. Decide during the RFP which handsets must pass acceptance, including the oldest low-specification Android your users actually carry, and buy the ones you do not have before the build starts rather than during the week you are trying to release.

Line three: release operations, which never stop

Every release consumes work that is not development: building and signing, writing release notes, updating store listings and screenshots when the UI changes, keeping the privacy and data safety declarations accurate, staging a rollout, watching crash rates, and occasionally handling a rejection and resubmitting.

Certificates and provisioning profiles expire on their own schedule, and an expired one discovered on a release day turns a routine deployment into an incident. Whoever owns this needs access to your store accounts, which is one more reason those accounts should be in your name from day one. The metric to watch during each staged rollout is set out in crash-free sessions.

Line four: the upgrade treadmill

This is the largest hidden line and the one most often deferred until it becomes a project. React Native publishes a documented upgrade path between versions, and the reason it needs one is that each move carries native build configuration, dependency versions and occasionally API changes with it.

Around that sit Apple's annual iOS release and its minimum submission requirements, Google Play's rising target API level for updates, Expo's own release cadence if you use it, and the third-party libraries that follow each of these at their own pace. Skip a year and each step gets harder; skip two and the app frequently cannot be built on a current toolchain at all, which converts a one-line fix into a migration.

The way to make this cheap is to make it routine. One planned upgrade window per quarter, scoped as maintenance rather than as a project, keeps the distance between your app and the platform small. The same discipline applied to dependencies is covered in security patching cadence.

Line five: support, priced honestly

The support decision is the one that most changes year-one cost, because it is the only hidden line with a published number attached. Our care plans run at $1,000 or ₹68,000 a month for Essential with business-hours cover in IST, $2,500 or ₹1,60,000 a month for Standard with 24 by 5 cover and a four-hour response, and $5,250 or ₹3,40,000 a month for Enterprise with 24 by 7 cover, a one-hour response and a named engineer.

Multiply before you compare build quotes. Essential care over twelve months is $12,000 or ₹8,16,000, which against a build starting at $17,500 or ₹11.2 lakh is a material share of the first year. That is not a criticism of the model; it is the actual cost of keeping a mobile app alive, and a vendor who omits it is not cheaper, only quieter. The tiers and what each includes are on the pricing page and in what a care plan should cost.

Support also absorbs the work that has no other home: a reviewer's question about a data declaration, a certificate that needs rotating, a third-party SDK that announces a breaking change with six weeks of notice. None of these are features, all of them are urgent, and a team without a support arrangement handles them by interrupting whatever was planned that sprint.

The costs on your side of the line

• Content and assets. App store screenshots for every device size, localised descriptions, an icon set and any illustration the design does not already own.
• Your people's time. Someone must answer integration questions, approve copy, test acceptance builds and sign off release notes, every sprint.
• Backend changes. Mobile requirements push work into your API: pagination, idempotency, versioning, push token storage and token refresh.
• Support volume. A published app generates store reviews, email and calls that someone has to answer within a day or two.
• Analytics interpretation. Instrumentation produces data; turning it into decisions is a recurring hour on someone's calendar.
• Compliance renewals. Privacy declarations, consent records and any annual security assessment your buyers expect.

When the extra spend is not justified

There is an honest case for refusing all of this. If your users would open the app a handful of times a year, the maintenance floor is real money spent on an artefact nobody uses, and a responsive web application avoids store review, device fragmentation and the upgrade treadmill entirely. We say so when we see it, and the wider version of that argument is in build or buy for React Native.

A second honest case is the app that exists only to satisfy an internal stakeholder. If nobody can name the metric the app should move, the running costs will outlive the enthusiasm that funded it. The right first purchase there is a short discovery engagement, not a build.

How to make the ledger visible before you sign

Ask every bidder for a three-year total, not a build price: the build, the subscriptions you will pay directly, the release operations estimate, the quarterly upgrade windows and the support tier. Ask which lines they will invoice and which land on your budget. Serious vendors produce this in a day, and our own React Native mobile application development proposals include the running lines alongside the build so the comparison is fair. The cost breakdown post shows what moves the build figure itself.

Related reading

Application maintenance contracts covers what belongs in the agreement that funds most of the lines above, and our maintenance and support service page lists what each tier includes from $1,000 or ₹68,000 a month.

A mobile quote that shows only the build price is not wrong, but it is answering a smaller question than the one you are asking.