Twice last year, a founder arrived with a half-finished Flutter app and the same story: the original agency loved Flutter, shipped fast, and disappeared. Now nobody on the hiring market in their city could maintain it. The code was fine. The decision was the bug.
The common belief
Flutter's pitch is genuinely attractive: one codebase, beautiful rendering, hot reload that makes demos sing. For an agency optimising its own velocity, it's a rational choice. The framework isn't bad — that's not our argument.
Choose the stack your next three hires already know, not the one your agency enjoys.
Our argument
We pick stacks for the team you'll have in three years, not the demo next month. In the GCC and most Western markets, the hiring pool runs JavaScript-deep: React on the web means React Native on mobile lets one team — and one mental model — cover both. Dart remains a single-purpose skill you hire for specially.
Second, the web matters more than cross-platform purists admit. Most of our clients need app + web + marketing site sharing logic and design tokens. React Native + Next.js shares meaningfully; Flutter Web remains the framework's weakest surface.
And when the app genuinely demands platform fidelity — deep animation, widgets, watch apps, the newest OS APIs on launch day — we go fully native Swift/Kotlin rather than reaching for any cross-platform layer at all. Cross-platform is a cost decision; native is a quality decision; Flutter sits awkwardly between.
When Flutter is still right
An existing Dart team. A hardware/embedded UI target. A market where Flutter talent is genuinely abundant. If that's you, Flutter is a fine answer — and we'll say so in the scoping call, even though we won't be the ones to build it.
- Stack choice is a hiring decision wearing a technical costume.
- Count the surfaces: if web matters, JS-stack sharing wins.
- Go truly native when fidelity is the point — skip the middle.