Mobile apps
Flutter apps, carried to the store.
I build Flutter apps for iOS and Android and take them through payments, CI and the store release. You get one engineer who owns the app, not a set of screens to integrate yourself.
- Interface
- State & storage
- Purchases
- Native & release
Recent mobile work
For the past year I have been the only mobile engineer on a production dating app for iOS and Android.
- 1,090+ commits, 99% of them mine; about 124k lines of Dart covered by about 112k lines of tests in 464 test files.
- In-app purchases on both stores: StoreKit and Google Play Billing 8, receipt verification, acknowledgement, entitlement polling and Google real-time developer notifications.
- The API layer extracted into a versioned Dart package, so one commit reproduces a code-push-patched build exactly.
- Paguely, my own app, built alone and live on the App Store and Google Play.
Figures as of October 2026.
What is included
A mobile project covers the app, the parts around it that decide whether it ships, and the first weeks after launch.
The app
Flutter for iOS and Android, Clean Architecture by feature, BLoC or Riverpod, offline storage, real-time chat and presence where the product needs them.
Payments
In-app purchases and subscriptions through StoreKit, Google Play Billing or RevenueCat, and Stripe for physical goods and deposits. Server-side verification, not trust in the client.
Native layer
Platform channels in Kotlin and Swift when a plugin is not enough: home-screen widgets, haptics, state restoration, camera and ML Kit, maps.
Release engineering
Signed builds per flavor in Codemagic or GitHub Actions, quality gates on every change, Shorebird code push for fixes that cannot wait for review, App Store Connect and Google Play Console.
Takeover
Existing app with problems? I start with an audit of the code, the build and the release setup, then fix in order of user impact.
From brief to store
The first installable build comes early; the store release comes when the main user path works on real devices.
Brief and design review
I read your brief and designs and list what is missing: states, errors, payments, store rules.
Skeleton build
Sign-in, the main screen and a test purchase working end to end, delivered through TestFlight and an internal Play track.
Features with gates
Each change passes static analysis, tests and a build before it merges.
Submission
Store listing data, privacy forms, review notes and answers to reviewers.
After launch
Crash reports and user feedback come first. Urgent fixes go out by code push where the stores allow it.
Questions
Why Flutter instead of two native apps?
One Flutter codebase serves iOS and Android, so features and fixes ship to both at once. When a feature needs native code, I write it in Kotlin or Swift and call it from Flutter.
Can you take over an existing Flutter app?
Yes. I start with an audit of the code, tests, build pipeline and store setup, write down what is risky, and then fix it in order of impact on users.
Do you handle in-app purchases and subscriptions?
Yes. I have shipped StoreKit and Google Play Billing with receipt verification, acknowledgement and entitlement checks, and I also work with RevenueCat and Stripe.
Do you publish the app to the App Store and Google Play?
Yes. I prepare signed builds, store listings, privacy forms and review notes, submit the app and answer review questions. The app is published under your developer account.
How do you ship urgent fixes after launch?
With Shorebird code push, Dart-level fixes can reach users without a new store review. Native changes still go through the stores.
Do you design the app as well?
I build from your Figma designs and check the result against them. If there is no design yet, I can work with your designer or start from a simple design system.
How is a mobile project priced?
Usually time-and-materials with tracked hours, after a written scope and an estimate. Send the brief and I will reply with questions and a plan.
Have an app to build or rescue?
CS-01Send the brief, the designs if you have them and your deadline.
- What the product does and who uses it.
- What exists already: designs, code, a backend, a store account.
- Your deadline, and anything fixed such as a launch date or a platform.