Flutter at Scale: One Codebase, Six Products
How SolvixaLabs ships EduNexus, Bloom Again and ElitePark Connect across iOS, Android and web from shared Flutter foundations.
Every SolvixaLabs mobile product — from the EduNexus parent app to Bloom Again's journaling experience — ships from Flutter. Here's how we make one framework serve six very different products.
A layered monorepo
Our Flutter monorepo has three layers:
core— networking, auth, storage, analytics, feature flags. Pure Dart, zero UI.solvixa_ui— our design system: tokens, typography, motion curves, and a component library that supports per-product theming.- Product apps — thin shells that compose core and UI packages with product-specific features.
A new product starts with roughly 60% of its code already written and tested.
Theming as a first-class citizen
EduNexus feels institutional and trustworthy; Bloom Again feels soft and calm. Both use the same components. Every component in solvixa_ui consumes design tokens — color, radius, motion duration — from a product theme, so brand personality lives in one file per product.
State management, pragmatically
We use Riverpod with a strict rule: providers model domain state, widgets own ephemeral state. Most of our production bugs historically came from blurring that line, so we lint for it.
Where Flutter earns its keep
Offline-first sync for schools with poor connectivity. Sixty-fps journaling animations that make a wellness app feel gentle. Instant hot-reload iteration during design reviews. One team shipping to four platforms on the same afternoon.
Cross-platform is a compounding advantage — but only if you invest in the foundations that make sharing real rather than aspirational.