React Native · iOS and Android

The prototype worked.Now make it scale.

AI-built apps are excellent at showing what a product should be and terrible at surviving a thousand real users. I rebuild them in React Native — keeping every product decision you validated and none of the code that cannot go to production.

Scope your app See the white-label option

1 codebaseiOS and Android from a single React Native app

6–10 wksWorking prototype to a build in both stores

100%Of the app is yours — source, pipeline and accounts

Prototype to product

From vibe-coded prototype to a real React Native app

The gap between an app that demos well and an app that holds up in the stores is not visual polish. It is everything underneath the screens.

Area

In the prototype

After the rebuild

Navigation

Screens wired together ad hoc; the back button loses your place

A typed navigation graph with deep links and restored state

Data layer

Every component fetches for itself — no cache, spinners everywhere

One client with caching, retries, and optimistic updates

Auth and secrets

Keys shipped inside the bundle, tokens in plain storage

Real session handling, tokens in the device keychain, silent refresh

Bad networks

Assumes the request always succeeds

Queued writes, cached reads, and honest offline states

Store readiness

Cannot be submitted — no signing, permissions, or privacy strings

Signed builds, entitlements, privacy manifests, review-ready

When it breaks

You find out from a one-star review

Crash reporting and release health, per build, per version

What I keep

Everything you learned. The screens, the flows, the copy, the ordering of steps, the features users actually touched. A prototype that has been in front of real people is the most detailed product spec you will ever get, and it is yours already.

What I do not keep

The code. Generated app code is optimised for producing a convincing demo on the first try, not for being changed fifty times. Rewriting it against a known-good spec is faster and cheaper than untangling it.

It has to stay smooth at 60fps

Long lists get virtualised, images get sized and cached, and animations run on the native thread. Jank that is invisible in a browser preview is the first thing a user feels.

The bundle is public

Anyone can unzip a shipped app. Keys move to the server, privileged calls move behind your API, and the client stops being trusted with anything it should not know.

The network is not a given

Elevators, basements, planes and rural coverage are normal operating conditions. Reads come from cache, writes queue and reconcile, and the UI says what is happening instead of hanging.

Two reviewers stand between you and users

Apple and Google reject for permission strings, account deletion, data disclosures and login requirements. I handle submission and the first round of review notes as part of the build.

White label

One app, skinned for every brand you run

If you need a solid mobile app more than you need a bespoke one, start from a product that already works and put your brand on it. One React Native app builds into a different installable product per brand, and one multi-tenant backend runs them all — content, sign-in, push, analytics and webhooks included. You are paying for configuration and launch instead of a ground-up build.

One folder per brand · everything else shared

13Content blocks a brand composes its screens from

6Screen kinds, from home pages to API-backed lists

74API operations, each documented with its errors

AAColour contrast checked on every brand before it builds

Two brands · the same code

Opposite looks, and not one line of code between them

Everything that differs — the name, the bundle id, colours, fonts, copy and screens — lives in one folder per brand. The rest is shared, so every improvement reaches every brand.

AutoCycle AI

BRAND=autocycle

Dark theme, purple accent, four tabs built for a product launch.

AutoCycle AI home screen: “Close the loop between support and engineering.” — Product

AutoCycle AI “How it works” screen with three numbered steps. — How it works

Persistent Software

BRAND=persistentsoftware

Light theme, cyan accent, a studio app that takes enquiries.

Persistent Software home screen: “Ship real software, faster than ever.” — Home

Persistent Software contact screen with an enquiry form. — Contact

Skinned to your brand, not badged with mine

Colours, typography, iconography, app icon, splash screen and tone all come from a theme file. Nothing in the app tells your users it started as someone else’s product.

Configured for each brand

Each brand gets its own content, locations, contacts and feature set from configuration rather than a code fork. Turning a module off for one brand does not put the others at risk.

Published under your accounts

Builds ship from your Apple and Google developer accounts, so the listing, the reviews and the users belong to you. One app per brand or one app with a brand picker — both work.

One codebase behind all of them

A fix or a new feature lands once and rolls out to every brand. Forking the app per client is what makes white-label programmes collapse in year two, so I do not do it.

Live in weeks, not quarters

Because the product already exists, launching a brand is a theming, configuration and store-submission exercise. The first one takes the longest; the ones after it take days.

You own what ships

You get the source, the build pipeline and the documentation. Hand it to an internal team later if you want to — the point is a working app, not a dependency on me.

The dashboard

Each brand runs its own app without calling you

Appearance editor with colour fields, a live phone preview and a contrast check for every text pair.

Restyle the app without a release

Change colours in the dashboard and watch the phone preview update as you type. Installed apps pick it up on their next launch — no rebuild, no App Store review — and a colour pair that fails contrast is refused, with the numbers.

Analytics page showing events recorded and app installations seen over 30 days, charted by day.

See what people actually do

Events by day, the most visited screens and installations seen, per brand. Events queue on the phone and send in batches, so a dropped connection never means a lost or double-counted tap — and nothing that identifies a person is stored.

Under the hood

From your website to a brand in one step

Paste a site and its colours come back as a brand. Every text pair is checked for contrast first, so a palette that looks fine on a desktop but is unreadable on a phone never ships.

One backend, every brand sealed off

Every brand runs on the same backend, and the database itself refuses to return another brand’s rows. With no brand bound, a query returns nothing at all — isolation is enforced below the code, not left to it.

Modules you can switch on

Onboarding and accountsProfiles and preferencesContent feeds and articlesCatalog and product browsingSearch and discoveryBooking and schedulingPayments and subscriptionsLoyalty and rewardsPush notificationsIn-app messagingReferrals and sharingSupport and help center

Anything specific to your operation gets built as a custom module on the same foundation, so it upgrades with the rest of the app instead of becoming the reason you cannot upgrade.

Screenshots are from the running app and dashboard, filled with example data — the people and figures shown are not real customers.

Your backend

Bring your backend, or let me build one

Most companies asking for a mobile app already have the data somewhere. The app should adapt to your systems — replacing them is a separate decision, made on purpose, not smuggled in by a mobile project.

Integrate with what you have

I meet your services where they are, however old they are. The integration layer absorbs the awkwardness so it never reaches the app or your backend team.

→A typed API client generated from your existing endpoints
→REST, GraphQL, gRPC — and SOAP or XML behind a thin adapter
→Your identity provider stays yours: OIDC, SAML, Cognito, Auth0, Firebase
→A small backend-for-frontend when your APIs are too chatty for mobile
→No schema changes and no migrations demanded of your team
→Contract tests so a server change cannot silently break the app

Or I build it to your spec

No backend yet, or one you would rather not extend. I build exactly what the app requires, sized to your traffic and your budget instead of a hypothetical future one.

→Postgres, a versioned API, and infrastructure as code on AWS
→Accounts, roles, and permissions designed around how you operate
→Push notifications, file storage, search, and scheduled jobs
→Payments and subscriptions through Stripe or the app stores
→An admin console your team uses without calling an engineer
→Yours outright — the code, the accounts, the deployment pipeline

What I build on

React NativeExpoTypeScriptFastAPINodePostgresAWSStripeFirebaseSentryApp Store ConnectGoogle Play

How a build runs

A signed build on your phone in two weeks

You get a new one every week after that. Nothing about the timeline depends on you trusting a status update.

Week 1
Pin down what the app actually is
I go through your prototype or your requirements screen by screen and write down the behaviour — including the parts that only exist in someone’s head. That document is what I build against, and it is yours whether or not we continue.
Weeks 2–3
Foundation before features
Navigation, data layer, auth, theming and the build pipeline land first. Both stores get a signed internal build in the first two weeks, so distribution is never the thing that surprises you at the end.
Weeks 3–7
Build the screens for real
Features ship in vertical slices — a real screen against real data on a real device, not a mock. You get a new TestFlight and Play internal build every week and can use the app while it is being built.
Weeks 6–8
Make it survive the real world
Slow networks, small screens, large fonts, permission denials, expired sessions and low-end Android hardware. This is where most of the difference between a prototype and a product gets earned.
Weeks 8–10
Submit, review, launch
Store listings, screenshots, privacy disclosures and account-deletion requirements handled for you. I drive the review process and turn around the reviewer’s notes rather than handing you a checklist.

Test on the phones your users own

A simulator on a fast laptop hides everything. I test on real devices, including the three-year-old mid-range Android a large share of your users are actually holding.

Native where it matters

React Native covers the vast majority of an app. Camera, biometrics, background location and hardware integrations get native modules when the ecosystem does not already have a good one.

Tests on the paths that cost money

Checkout, login and sync get end-to-end coverage on both platforms. I do not chase a coverage percentage on screens whose worst failure is a misaligned label.

Ship without waiting on review

Over-the-air updates push JavaScript fixes to users in minutes, with store submissions reserved for native changes. A typo does not cost you a three-day review cycle.

Notifications with a reason to exist

Push is the strongest retention tool a mobile app has and the fastest way to get uninstalled. Segmentation, quiet hours and per-category preferences are designed in from the start.

Know what happens after launch

Crash reporting, release health and product analytics are wired up before the first submission, so week one is spent reading real numbers instead of guessing.

Timelines above describe a typical single-product build. A white-label launch on an existing foundation is considerably shorter; an app with heavy hardware or offline requirements runs longer. I scope yours before quoting it.

Send me the app you already built.

Every engagement starts with a review of what exists today — a prototype, a spec, or a rough idea of the app your brand needs. You get the findings whether or not you hire me to build it.

An honest read on what your prototype is worth keeping
The features that stand between you and a store approval
A phased plan with a real timeline and a real number

Schedule a call Get in touch