Mobile App Development
React Native apps for iOS and Android from one codebase, with the Supabase backend and the web dashboard behind them. Store submission included.
React Native apps for iOS and Android, built from one codebase and shipped to both stores. With the web dashboard behind them, when the office needs to see what the app collects.
An app is only half the job. The other half is the account system, the database rules, the store review, and the admin screens somebody uses on a laptop the next morning.
My rate is $14 per hour. A defined app build is quoted as a fixed price up front, so the number does not move unless the scope does. Store accounts are yours and paid directly: Apple charges a yearly developer fee and Google a one-off registration. Ongoing work runs as a monthly block you can scale.
What I build
Field and shift apps
Timers, job records, checklists and forms used by people standing up, on a phone, sometimes with no signal. State is held on the device as well as the server so a locked screen does not lose the work.
Apps with a web dashboard behind them
The phone collects, the office reports. One database, two front ends, one set of access rules. I built exactly this for Premier Gaming Massage: a React Native app on both stores and a React dashboard on Vercel.
Location-aware apps
Permissions handled properly on both platforms, the site detected rather than typed, and a map when the job needs one.
Store submission and what follows
Bundle identifiers, signing, icons, privacy declarations, store listings and the review itself. Then the updates, which is where most apps quietly stop.
The stack, and why I picked it
One codebase for two platforms only pays off if the parts underneath are boring and well documented.
One TypeScript codebase for iOS and Android, with native modules where a feature actually needs them. Your next developer can read it.
Postgres with row level security, so the access rule sits in the database where both the app and the dashboard have to obey it.
For the dashboard, because it builds fast and deploys as static files to Vercel.
Server state on the web, so the office sees current numbers without a refresh button.
Start to finish
- 01Scope the screensEvery screen drawn and agreed before any code, because a screen added in week three is cheaper on paper than in the build.
- 02Data model firstTables and access rules go in before the interface, so the app and the dashboard are never arguing about who can read what.
- 03A build on your phone in week oneInstalled on a real device early, because a simulator hides everything that matters about a phone app.
- 04Then the dashboardBuilt once the app is producing real rows, so the reports are shaped by actual data.
- 05Store submissionSigning, declarations, listings and review, handled by me rather than handed back to you as a checklist.
- 06Hand overThe repository, the store accounts in your name, and a written note on how to ship the next version.
One job, not two
A codebase that runs on both platforms still has two review processes, two signing setups and two sets of privacy declarations.
That work is in the quote. An app that builds but cannot be submitted is not finished.
Recent work
Before hiring
React Native or fully native?
React Native for almost everything that is forms, lists, timers and reports. If you need heavy graphics or deep hardware access, I will tell you to go native rather than take the job.
Can you publish under my developer account?
Yes, and that is the right way round. The accounts stay in your name and I get access, not ownership.
How long does store review take?
Apple is usually a few days and can ask for changes. Google is normally faster. I build the declarations correctly the first time, which is what avoids most rejections.
Do I need the web dashboard too?
Only if somebody has to report on what the app collects. If the phone is the whole job, skip it.
Can you take over an existing app?
Yes. I audit the codebase and the store setup first and tell you honestly whether it is worth continuing.
What about updates?
Bug fixes and new versions run under maintenance or are billed hourly.
Built with this service
Other ways I can help
I build software, and I measure whether it works.
The same questions I research are the ones I ask on client builds: is it reliable, is it fast, is it easy to use, and is it secure. Those four drove satisfaction in my ICT portal study, and they shape how I scope and test every project.