Role
Head of Product
Timeline
Nov 2025 - 2026
Key Skills
iOS
Swift
Android
Kotlin
React Native
one codebase, one pipeline
Project Overview
Symplast is the leading mobile EHR, practice management, and CRM for plastic surgery and medspas, serving more than 3,500 practices. The apps that clinics rely on every day were two separate native builds: Swift on iOS, Kotlin on Android. That split was quietly taxing the whole roadmap.
As Head of Product, I led the migration to a single React Native platform. The work was as much a product decision as a technical one: parity gaps between the two apps were product debt, and the fastest way to ship more was to stop building everything twice.
Key Challenges
- Every mobile feature was built twice, once in Swift, once in Kotlin, doubling the cost of the roadmap.
- Feature parity drifted between iOS and Android, so clinics had different experiences.
- Engineering capacity was split across two stacks, slowing delivery for a growing base.
- The migration had to happen without disrupting practices mid-workflow.
Solution & Approach
Parity Audit First
Cataloged every gap between the iOS and Android apps, ranked them by real usage, and made closing them the definition of done for the new platform, so the migration paid down product debt instead of carrying it forward.
One Codebase, Shared Standards
Moved the team to a single React Native codebase with a shared component library and one release pipeline, so a feature is built, reviewed, and shipped once for both platforms.
Ship-While-You-Migrate
Migrated screen by screen behind feature flags, keeping the app releasable throughout, so practices never felt the transition and the roadmap kept moving.
Results & Impact
50% increase in mobile engineering capacity
Retiring the second codebase freed the team to spend capacity on the roadmap instead of on building everything twice.
Feature parity restored across platforms
iOS and Android clinics now get the same features at the same time.
One codebase, one release pipeline
A single build path replaced two, cutting duplicated review, QA, and release work.
Faster feature delivery
New mobile features are built once and reach both platforms sooner.
Key Learnings
Parity Gaps Are Product Debt
Treating the iOS/Android differences as a product problem, not a cleanup task, is what made the migration worth doing. Closing the gaps was the point, not a side effect.
Measure Capacity in Features, Not Lines
The win wasn't fewer lines of code; it was how much more the same team could ship once they stopped maintaining two of everything.