Baritastic — two codebases became one, with nothing patients relied on changed
A bariatric-care app used daily by people managing a medical recovery. A million downloads, half a million users, running since 2018 on two separate codebases — Android in Java, iOS in Objective-C — with crash-free sessions down to 98%.
I led the consolidation onto Flutter as mobile lead, with four to five engineers. The rule we worked to was that no feature could change. Not improve, not simplify — not change. People were tracking a medical recovery in this app and a surprise is worse than an imperfection.
So we migrated screen by screen, lowest-risk first, and verified each one against the behaviour of the live app rather than against the spec — because an app running for seven years does a hundred things nobody ever wrote down. I chose the architecture, Bloc with Clean Architecture, and built the tracking features, reminders and the health-platform integrations across HealthKit, Health Connect and Samsung Health.
Crash-free sessions rose from 65% to 98%. The install dropped from 150MB to 60MB. Two codebases became one, and shipping a change stopped meaning writing it twice.
One thing I’d do differently: our staged 1% rollout didn’t account for the health-platform integrations raising the minimum OS version, which cost about 6–8% of users their health sync until we caught it. Stage by OS version, not just by percentage.
0
21
Ticket Tribe — a social network built around event tickets
Instagram, but the posts are events and tickets. Discover a match or a concert, buy a seat, collect the ticket, post about it, and talk to the people going. Android and iOS, built from scratch, by one engineer.
I was the only mobile developer on it for six to eight months and worked directly with the client on requirements rather than from a finished spec. The architecture is local-first — optimistic actions, an ordered mutation queue, idempotent retries and conflict resolution — because people use an app like this in a stadium, on a crowded network, and an action that silently fails in that moment is the one that loses you the user.
On top of that: a community chat with voice messages, event discovery on Google Maps, and a WebView seatselection flow handed off to native. I wrote it test-first from day one, pasting real Postman responses into fake repositories as expected results — which is how most of the backend-to-UI mismatches got caught before they reached a screen.
Delivered at roughly 80%. The client’s funding stopped before release, so it never reached either store
0
26
ONEai Health — a clinical monitoring app, from ring basics to seventeen vitals
Patients enrol through their healthcare provider and wear an FDA-cleared smart ring. The app had been live about a year when I joined, and its public reviews weren’t about polish — they were about readings that didn’t arrive and a ring that wouldn’t stay connected.
I came in as primary Android engineer and built most of what the product does today. The core problem was that health data arrived three different ways — the ring over Bluetooth, Android Health Connect, and the patient typing it in — and each path had grown its own handling. I converged all three onto one per-vital model, so every one of the seventeen vitals renders, charts and uploads identically no matter where its numbers came from.
From there: seventeen health-vital surfaces, Health Connect sync, a structured daily diary and an AI chatbot, across roughly seventy-five screens. Then the client brought a new design, and I reimplemented the entire interface against it without touching the business logic underneath — which is the whole argument for keeping the two apart. Live on the App Store and Play Store, now maintained by an internal team
0
34
Sales-Edge-AI — an AI sales coach for Android and iOS, from one Kotlin codebase
A sales rep records a client meeting on their phone. The app transcribes it, scores the conversation, and files it against the right opportunity in the pipeline. Twenty-five screens, fourteen features, Android and iOS — built by one person.
The whole product runs on a single Kotlin Multiplatform codebase with Compose Multiplatform for the UI, which means both apps share their screens, not just their networking layer. That works right up until it doesn’t, and the place it doesn’t is recording — the one thing the product lives or dies on.
Android and iOS have different audio APIs, different rules about what a backgrounded app may do, and different ways of taking the microphone away mid-session. So the recording session sits behind one interface in shared code and is implemented twice underneath: MediaRecorder with a foreground service on Android, AVAudioRecorder reached through a C-interop bridge with a background audio session on iOS. Fourteen platform boundaries like it across the app. Everything above them is shared.
0
40