React Native

What a React Native app costs to build

Nobody in this market gives founders a straight answer, so here is mine: what moves the number, what keeps it down, and the part almost everyone leaves out of the budget.

What actually moves the number

Three things account for most of the variation between a cheap app and an expensive one. Everything else is detail.

Screens: how many, and how custom

A list, a detail view and a settings page is a very different job from twenty screens with bespoke animation on each. The count matters less than the repetition: ten screens that share a pattern cost far less than five that each need their own design and layout logic.

Accounts and a backend

This is the single biggest fork in the road. An app that stores everything on the device has no servers, no login, no password resets, no sync conflicts and no ongoing hosting bill. Add accounts and you have added a second product behind the first one, plus a permanent running cost.

It is worth asking hard whether you need them in version one. Wallety, one of my own apps, has no accounts at all, and that decision removed months of work and every hosting invoice since.

Payments across two stores

Subscriptions and in-app purchases are more work than they look. Apple and Google each have their own receipt validation, their own edge cases for refunds, restores, upgrades, downgrades and grace periods, and their own review expectations for how a paywall must behave. Budget for it as a feature in its own right, not a checkbox.

What keeps the cost down

One codebase for both platforms

This is the reason to pick React Native in the first place. You are not paying for an iOS app and then paying again for Android. The saving is real, but it is not total: platform differences in navigation, permissions, notifications and store review still need handling on both sides.

A genuinely scoped v1

Most app ideas are two or three apps wearing a trench coat. The single largest cost reduction available to you is deciding what ships first, and it costs nothing to make that decision well. A scoped first version that reaches real users beats a perfect third version that never ships, and it tells you which of the remaining features anyone actually wants.

The part everyone forgets

Founders budget for the build and stop there. The build is the part you can estimate, and it is not the part that surprises people.

• Store listings. Screenshots at several device sizes, descriptions, keywords, a privacy policy, data declarations for both stores.
• Review rejections. Both stores will reject something eventually. It is routine, it is survivable, and it costs days.
• The first month after launch. Crashes on devices you have never seen, the flow everyone misunderstands, the setting people keep asking for.

On my own apps this is not a footnote. Wallety's heaviest month of development was June, five months after it was already live, at 350 commits. Qurany had 628 commits in a single month last July. If you take one number from this page, take that one: plan for the year after launch, not just the build.

Why not an hourly rate

You will see hourly rates quoted for React Native work, and they are close to useless when you are deciding whether to build something. You cannot turn a rate into a total without knowing how many hours your app is, which is the thing you were trying to find out.

A scoped price also puts us on the same side: I am paid to ship the thing we agreed, not to spend hours. I do work hourly for reviews, audits and unblocking an existing team, where the scope genuinely is open, but not for builds.

How to get a real number

Send a paragraph describing what you want to build. Not a spec, a paragraph. You will get back what I would build first, what it would cost, and whether I think I am the right person for it, which is occasionally no.

hello@orbitapps.net, or read more about working with me on React Native.