What I build: one React Native codebase for iOS, Android and web
Building the same app separately for iOS, Android and web means three codebases, three sets of bugs and features that arrive on one platform before the others. With React Native and Expo, one codebase serves all three. A feature is built once, a fix ships once, and every user gets the same product.
An app is rarely just screens. I build the parts behind it too, so the app, the API and the data model are designed together rather than negotiated between separate teams.
- React Native and Expo apps for iOS, Android and the web from one codebase
- Backends for the app in Python (FastAPI, Django), Node.js or Firebase
- Sign-in, roles and multi-tenant access, for example agencies, coaches and clients in one product
- Billing with Stripe, and in-app purchases where the store rules require them
- Real-time sync, so data updates on every device without a manual refresh
- Wearable and device integrations, and AI features inside the app
Cross-platform app development: when React Native is the right choice
React Native suits most business apps: products built around accounts, forms, lists, dashboards, payments, messaging and data that has to stay in sync. For those, one shared codebase usually costs less to build and much less to maintain than separate native apps, and a web version comes almost for free.
It is not the answer to everything. Apps whose core is heavy 3D, advanced camera or audio processing, or very deep use of one platform’s newest features may be better built natively, at least in part. I’ll tell you which camp your app is in during discovery, before you commit to a build.
The backend, billing and data behind the app
Most of the hard problems in a mobile product live behind the screens. Phones lose signal, users switch between devices and payments have to be right every time. I design the data model and sync so the app behaves sensibly when the connection drops and catches up correctly when it comes back.
For many products Firebase is a fast, sensible start: Firebase Auth for sign-in and Firestore for real-time data. Where the product needs complex business rules, reporting or integrations, a Python or Node.js API with PostgreSQL is often the better fit. I choose based on what the product needs over the next few years, not only the first release.
- Offline-ready data and real-time sync across phone, tablet and web
- Stripe subscriptions and payments, with webhooks handled safely so nothing is charged or granted twice
- Push notifications for the events your users need to act on
- Role-based access and tenant separation, so each user only sees their own data
- Admin dashboards and web portals for the staff who run the service
- Integrations with wearables, health platforms and third-party APIs
App Store and Play Store release
Getting an app approved and into users’ hands is its own piece of work, and it is often where first-time projects stall. I handle the release as part of the build: builds and signing, test releases to your team, store listings and the review submission for both the App Store and Google Play.
Apple and Google each have their own rules on payments, privacy disclosures, permissions and sign-in, and an app that ignores them gets rejected. I design with those rules in mind from the start, so the review is a formality rather than a redesign. After launch, updates go out through the same release process.
Securing mobile apps and the APIs behind them
Anything shipped inside a mobile app can be read by someone determined enough, so an app should never hold secrets or be trusted to enforce rules on its own. The real security boundary is the API. I make sure every request is authenticated and checked server-side, that one user cannot reach another user’s data by changing an ID, and that tokens are stored and refreshed safely on the device.
This comes from the same background as my security work: an MSc in Cyber Security and Forensic Information Technology from the University of Portsmouth, encryption, MFA and RBAC implemented on a real-time industrial safety platform at Bodytrak, and recognition as Cybersecurity Engineer of the Year 2026 in the Corporate LiveWire Innovation & Excellence Awards. Health, finance and personal data get the controls they need from the first release.
Case studies: ERA Health, Hero Trainer, NPhase Health and Brakeproof
ERA Health’s ERAFit is a B2B2C coaching platform covering training programmes, nutrition, lab results, wearables, CRM and payments. I designed and built it end to end as a single Expo and React Native codebase serving iOS, Android and web, with Firebase Auth and Firestore, Stripe and Affirm billing, Gemini on Vertex AI for AI-assisted nutrition and lab analysis, and a multi-tenant structure for agencies, coaches and clients.
Hero Trainer is a gamified fitness rewards platform with React and React Native front ends and a Python, Django and Node.js backend for activity tracking, rewards and real-time synchronisation across web and mobile. NPhase Health connects participants’ wearables, such as Fitbit and Strava, through the Terra API, with OAuth token refresh, webhook ingestion and Celery and Redis pipelines delivering daily metrics into REDCap Cloud for research teams.
Brakeproof, my own product, is a safety layer for AI agents: safe actions run, risky ones wait for human approval and dangerous ones are blocked. Its React Native approvals app, currently in beta, lets a person review and approve a risky agent action from their phone, with a snapshot taken first, so a security decision can be made wherever they are.
What you get
- A written scope and architecture for the app, backend, data model and integrations
- A React Native and Expo app for iOS, Android and, where useful, the web, from one codebase
- The backend, sign-in, billing and real-time sync the app needs, deployed in your own accounts
- Security built in, with the API checked as the real boundary, and a security review before launch
- App Store and Google Play submission, with test releases to your team first
- Weekly demos on real devices throughout the build
- Documentation, release instructions and a handover session for your team
How it works
Step 01 · Before the build
Discovery and scope
NDA first, then working sessions on your users, the core journeys, the platforms you need and the integrations involved. You get a written scope, milestones and a fixed or capped price before any work starts.
Step 02 · Typically the first 1–2 weeks
Architecture and design
The data model, sync, backend, payments and security agreed in writing, plus the key screens, so store rules and offline behaviour are designed in rather than patched later.
Step 03 · Agreed milestones
Build in iterations
Hands-on development with weekly demos and test builds you can install on your own phone, so you see the real app as it grows.
Step 04 · Before go-live
Store release and launch
A security review, testing on real devices, store listings and submission to the App Store and Google Play, then a staged launch to users.
Step 05 · At launch
Hand over
Documentation, release instructions and a handover session, so your team can ship updates without me.
Proof
“Steady progress, predictable delivery, and code that’s easy to review and integrate.”
Sean Metcalf
Founder, getKaivo
“His knowledge of security, cryptography, and database design was of crucial importance to our product’s successful development.”
Rod Ast
CEO & Founder, 911 Vault
“Particularly impressed by Arslan’s initiative in implementing robust security measures for SOC 2 and ISO 27001 standards.”
Matthew Mammana
Programme & Operations Manager
Price
From £12,000. For a scoped build covering the app, its backend and store release, with a fixed or capped price agreed in writing. Every engagement starts with a free 1-hour intro call, and you get a written scope with a fixed or capped price before any work starts.
FAQ
How much does it cost to build a React Native app in the UK?
My Build Projects start from £12,000 for a scoped first release, covering the app, its backend and store submission. The price depends on the number of screens and user roles, payments, integrations such as wearables, and how much the app has to work offline. You get a fixed or capped price in writing before work starts. Apple and Google developer accounts and hosting are billed to you directly.
How long does it take to build and launch a mobile app?
It depends on scope, so I don’t promise a timeline before discovery. The main drivers are the number of core journeys and user roles, payments, device or third-party integrations, offline needs, and whether designs and a backend already exist. Store review adds a short, variable wait at the end. The written scope sets out milestones you can plan around.
Do you sign an NDA, and who owns the app and its code?
Yes, I sign an NDA before discovery. You own the code and the intellectual property once the work is paid for, and the app is published under your own App Store and Google Play accounts, so the listing, the users and the code stay with you.
React Native or native iOS and Android: which should we choose?
For most business apps, React Native is the better choice: one codebase for iOS, Android and the web, lower cost and features that arrive on every platform together. Apps built around heavy 3D, advanced camera or audio work, or very new platform features may need native code, and I’ll say so in discovery rather than after the build.
Can you build the backend and web dashboard as well as the app?
Yes, and it usually works better that way. I build the API, database, payments, admin dashboard and integrations alongside the app, so the whole product is designed together and one person is accountable for how it fits.
Can you take over an existing React Native app?
Yes. I review the code, dependencies, backend and release setup first, then tell you what needs fixing, upgrading or rebuilding before we agree the scope. Outdated dependencies and a fragile release process are the most common problems, and both can usually be fixed in stages.