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.
Related writing
- React Native vs Flutter — An Honest Take After Shipping BothA practical comparison of React Native and Flutter from someone who has shipped production apps in both — team fit, native modules, performance, and the decision that actually matters.
- Expo vs Bare React Native — When to Actually EjectWhy Expo is the right default for most React Native apps in 2026, what the prebuild workflow changed, and the specific signals that mean you genuinely need to go bare.
- Offline-First Mobile ArchitectureHow an offline-first mobile app really gets built: local database as source of truth, a mutation outbox with idempotency keys, client-generated IDs, sync cursors, and the UX that's harder than sync.