React Native app maintenance cost in 2026

If a React Native app is already in production, maintenance budget should not be whatever is left after the project. It is a separate operating plan: OS upgrades, store compliance, monitoring, regression testing and the small post-launch backlog.

For most business apps, a realistic starting point is EUR 2,500 - 6,000/month for 20-60 hours. A simpler Expo app with a few workflows may sit near the lower end. A commerce, B2B, logistics or fintech app with checkout, many integrations and SLA pressure will usually need 40-60h or more.

The most expensive scenario is not the retainer. It is having no maintenance owner, stale SDKs, a rejected App Store build one week before a campaign and a team that first has to reverse-engineer someone else's code.

Technical maintenance covers React Native, Expo SDK, Xcode, Android Gradle Plugin, target API, npm dependencies, certificates, build configuration and security patches. These are not cosmetic tasks: Apple and Google regularly change minimum requirements for app submissions and updates.

Quality maintenance covers Sentry or Firebase Crashlytics, alerts for crash-free session drops, ANR analysis, cold-start checks, regression testing for login, checkout, payments, push notifications, deep links and analytics events.

Product maintenance covers small changes within the monthly hours: copy, banners, form validation, a small screen, GA4/Segment event, UI fix after an API change. A new loyalty module, ERP integration or checkout rebuild is a separate DDT-scoped effort.

A 20h plan, usually EUR 2,500 - 3,500/month, fits a stable app with one backend, few integrations, no revenue-critical checkout and decent delivery documentation.

A 40h plan, usually EUR 3,500 - 5,000/month, is the common tier for commerce, B2B and operational apps. It leaves room for monitoring, SDK updates, regression checks, small changes and fast response when backend, payments or store requirements change.

A 60h+ plan, usually EUR 5,000 - 8,000+/month, is justified by high traffic, white-label builds, payments, multiple environments, custom native modules, BLE/IoT, sales seasonality, compliance or an SLA closer to mission-critical software.

Cost rises when the app has custom native modules, unusual payment SDKs, offline mode, multiple brands, several countries, submissions under different store accounts or a backend without API versioning.

Cost also rises when the previous team left little test coverage, no release runbook, no demo accounts for review, manual CI/CD, an unstable EAS/Xcode pipeline or crash monitoring that collects errors nobody reads.

Cost drops when the app uses Expo where it fits, has a proper staging environment, automated builds, a release checklist, tests for critical flows, architecture notes and a backlog split into incidents, maintenance and features.

SLA must separate incident types. Critical means app down, checkout broken, mass crashes or users unable to log in; response should be measured in hours. Normal means a bug without revenue impact; 24-48h on business days is usually reasonable.

The upgrade calendar should include at least: quarterly dependency review, planned Expo SDK upgrades, an annual larger React Native upgrade, Apple requirement monitoring, Google Play target API checks and a feature freeze before sales peaks.

Official React Native and Expo docs recommend incremental upgrades, and Expo notes production apps should use development builds instead of relying on Expo Go support for older SDKs. That is an argument for planning, not for postponing upgrades.

Access to Sentry or Firebase Crashlytics is not maintenance by itself. Maintenance is the rhythm: someone reviews errors, groups regressions, compares crash-free sessions, checks affected devices and decides what goes into the next release.

A monthly report should show crash-free users/sessions, top 5 crash groups, Android ANRs, app start time, API errors, failed payment percentage, store status, risky dependencies and the maintenance backlog for the next month.

For the CFO, the report should answer: what did the maintenance hours buy? For the CTO: is production risk going down or up? For the product owner: which small changes actually improve adoption.

A commerce app is not just screens. It lives where catalogue, promotions, payments, ERP, WMS, push, CRM and analytics meet. One backend change can break cart, order status or coupons.

B2B adds user roles, contract prices, credit limits, repeat orders, approval flows and integrations with systems that were often not designed for mobile. That raises regression and testing effort.

In the SFD case, post-launch work was not only bug fixing. Store quality, iOS/Android updates and traffic peak stability mattered. With 100k+ downloads and a 4.9 App Store rating, app maintenance is part of the product, not an add-on.

At GMI, maintenance is treated as continued product responsibility. After DDT and delivery, the team knows the architecture, technical decisions, risks and business goals, so the retainer does not start by learning the project from scratch.

A typical package covers the maintenance backlog, monitoring, upgrade plan, release support, small changes and advice on decisions: when to add a feature, when to rewrite a part, when to move in-house and when not to touch a stable part of the system.

If another vendor built the app, the first step is a technical audit: repository, dependencies, CI/CD, store accounts, monitoring, architecture, tests, API and release risks. Only then do we set a realistic retainer.