Service 02
Apps that feel native,
from one codebase.
Cross-platform mobile work, built so it doesn't feel cross-platform. I ship to both stores from a single codebase — including the parts most quotes leave out: the store submissions, the review rejections, the offline states, and what happens when the network drops mid-transaction.
Start a project ↗What I build
- Consumer apps
- Full products from empty repo to App Store and Play listing, including the store assets and review process.
- Offline-first apps
- Local-first data with sync, conflict handling and queued writes. If your users will ever be on bad connectivity, this isn't optional.
- In-app payments
- Stripe, RevenueCat, and native store billing. Subscriptions, one-off purchases, and the receipt validation nobody remembers to scope.
- Companion apps
- Mobile clients for an existing web product, sharing types and API contracts with what you already run.
- App rescue
- Taking over an abandoned React Native or Flutter codebase, getting it building again, and shipping the next release.
Stack
- Cross-platform
- React Native · Expo · Flutter
- State & data
- TypeScript · Zustand / Redux · SQLite · WatermelonDB
- Backend
- Node · Supabase · Firebase · REST / GraphQL
- Release
- EAS Build · OTA updates · App Store / Play Console
Whether this is a fit
A good fit if
- You want one codebase for iOS and Android rather than two teams
- The app needs to work properly offline, not just show a spinner
- You need someone who has actually shipped through app review before
Probably not if
- You need heavy platform-specific native work — go native, and I'll say so
- The app is a thin wrapper around a website; you may just need a good mobile site
- You want it in two weeks
Questions I get asked
React Native or Flutter — which will you use?
Depends on your team and your integrations. If you have React developers, React Native shares far more. If the product is animation-led, Flutter. I've shipped both and I'll give you the honest tradeoff rather than a default.
How do you charge?
Three ways, whichever suits the project: an hourly rate, a monthly contract for ongoing work, or milestone-based payments tied to agreed deliverables. We settle which one on the scoping call, before any work starts.
Do you handle App Store submission?
Yes — listing, assets, review, and the rejections. This is genuinely the part that surprises first-time clients.
Can you add to an existing app?
Yes. Feature work and takeovers on existing React Native and Flutter codebases are a regular part of what I do.
Who owns the developer accounts?
You do. Apps publish under your Apple and Google accounts, not mine — you should never be locked to a contractor for your own listing.