Three teams, three backlogs, three QA cycles, and a product manager trying to get the iOS version of a feature to behave like the Android one before anyone notices the gap in production.
That is the operational reality for companies that grew by splitting engineering per platform, and the real cost never shows up in headcount, it shows up in time-to-market.
The problem starts with duplicated business logic: the same validation rules, the same auth flows, the same data models, rebuilt three times in three languages. When a rule changes, three PRs, three reviews, and three deploys need to line up. I
Why separate teams per platform slow products down
Coordination between separate teams eats more time than it looks like on a roadmap: alignment meetings, contract documentation, priority negotiation when one team is ahead and another is behind.
It absorbs between 15% and 25% of engineering time depending on process maturity. For a CTO with a three-month launch window, that tax can decide whether the product ships on time.
- No shared API contract means mobile and web consume the backend differently, and the same entity drifts apart with no single source of truth.
- Mobile and web model authentication separately, producing two versions of the user object with no clear owner.
- Independent backlogs mean the same requirement gets interpreted differently per platform, stretching timelines without expanding scope.
How to structure an effective cross-platform squad
The answer does not start with picking a framework, it starts with the squad's structure. An effective cross-platform team has 5 to 8 people sharing one backlog, one CI/CD pipeline, and one repository (or a mono-repo with clearly scoped packages).
Inside that squad, the platform steward is the key role: engineers fluent in Flutter who also carry native iOS or Android experience.
They know when a behavior needs a platform channel and when a native package beats fighting an abstraction that does not fit. You typically need at least one steward per target platform.
The rest of the squad works on the shared codebase, comfortable with state management (Riverpod, Bloc), clean architecture, and widget-level testing, the kind of range covered in our own notes on what makes a strong Flutter developer.
A Next.js specialist covers cases where a transactional PWA needs SSR or SEO that Flutter web still does not solve as well. When the internal team lacks these profiles, staff augmentation skips a long hiring process without lowering the squad's bar.
Which code-sharing strategies actually work
Flutter shares 70% to 95% of the codebase across iOS, Android, and web from a single Dart project, including UI, business logic, networking, and state management.
For business logic that needs to live outside Flutter, such as an SDK consumed by other native teams, Kotlin Multiplatform lets you write once and compile for iOS and Android with real native interop. KMP fits well as a shared domain layer when a product has native components that will not migrate to Flutter.
That decision, KMP or a native Kotlin module, should be based on measured evidence, not preference.
A mono-repo with separate packages lets features evolve independently without breaking other builds, using a melos bootstrap for local dependencies and a CI pipeline that only tests the packages a given PR touches.
Platform · Build command · Deploy target
iOS · flutter build ipa --release · TestFlight via Fastlane
Android · flutter build appbundle --release · Google Play
Web · flutter build web --release · Firebase Hosting or AWS S3 + CloudFront
Codemagic orchestrates that in a single pipeline with parallel builds per platform, cutting the release cycle from days to hours.
A storefront with checkout, like the ones we build for ecommerce clients, runs well on Flutter web, while a content landing page runs on Next.js on the same domain.
What changes in the final outcome
Sharing a codebase lowers maintenance costs in a concrete way, because every fix and every feature ships once. Time-to-market compresses because there are no cross-team blockers waiting on each other to coordinate a release.
- ProWallet, an instant-payments fintech for construction in the US, shipped iOS and Android from one codebase with a single team.
- CAA Club Group, Canada's largest automobile association with 7M+ members, got roadside assistance tools delivered by one unified team across mobile and web.
- Tracer Golf, in Toronto, passed 13,200 downloads without duplicating effort across platforms.
- MyBotPal, Huawei's AI voice assistant, needed hardware integration and multi-language support, handled by one squad instead of fragmenting, the kind of scoping product discovery settles before development starts.
At Somnio Software we have built more than 170 applications this way through full product development, using Flutter as the core alongside Next.js, Kotlin, Swift, Nest, Firebase, and AWS as each product needs.
Structure matters more than the framework: a 5-to-8-person squad with platform stewards ships faster, with fewer bugs, at lower cost than three teams working in parallel.
If your team is moving from separate platform teams to one cross-platform squad, let's talk about how to structure it for your product.
Frequently asked questions
Does Flutter fully replace native iOS and Android code?
Flutter shares 70% to 95% of the codebase, but cases like HealthKit integrations or legacy modules still need native code. Those are handled through platform channels, kept isolated in their own package.
How many people does a cross-platform squad need to work well?
5 to 8 people is the range that balances speed and coordination. Fewer than that can create bottlenecks when several platforms need attention at once. More than that tends to recreate the coordination overhead the unified model is meant to remove.
When does Kotlin Multiplatform make more sense than Flutter for shared code?
KMP fits when business logic needs to be consumed by native teams that will not migrate to Flutter, for example a legacy Swift module or a hardware-specific integration. Flutter stays the main vehicle for the UI and the product as a whole, while KMP acts as a shared domain layer.
What happens to SEO if the app has a web component?
Flutter web covers transactional experiences well, but content that needs indexing or server-side rendering is better served by Next.js. Both can coexist on the same domain through a reverse proxy, without either one replacing the other.
How much engineering time gets lost with separate platform teams?
Coordination between separate teams absorbs between 15% and 25% of engineering time depending on process maturity, on top of maintaining duplicated business logic across platforms. A unified team removes that overhead by sharing one backlog, one pipeline, and one product context.
Shipping across platforms from one codebase is where a well-structured squad pays off, it is how ProWallet went live on iOS and Android without a team per surface.
At Somnio Software, we work closely with companies to design and build high-quality digital products using modern technologies and development best practices.
If you're looking for a trusted partner to bring structure, expertise, and innovation to your next software project, we'd love to connect. Contact us to learn how we can help turn your product vision into reality.
