Why we chose Flutter for all our mobile apps — and what we learned

Every mobile development team eventually settles on a stack. After shipping apps in multiple frameworks, we made Flutter our default at VE.KE. Here is the honest version of why.

The Problem with React Native

React Native's bridge architecture introduced performance unpredictability that was hard to debug. On lower-end Android devices — which are the majority in the Kenyan market — the JavaScript bridge overhead was noticeable. We were spending too much time on performance tuning instead of building features.

Why Flutter Won

Flutter compiles to native ARM code. There is no bridge. The widget engine renders directly to the canvas, which means consistent performance across devices. On a KES 8,000 Android phone, a Flutter app feels like a native app.

The other factor: a single codebase that genuinely works across iOS and Android without platform-specific workarounds. For B2B apps where we need to ship fast and support both platforms, this matters.

What We Have Learned

State management matters more than you think. We standardised on Riverpod after trying Provider and BLoC. It scales cleanly as apps grow.

Dart is not a barrier. Engineers learn Dart in days if they know any typed language. It is not a reason to avoid Flutter.

The ecosystem is mature enough. M-Pesa SDKs, Firebase, camera, GPS, biometrics — everything we need has a well-maintained package.

When We Would Not Use Flutter

If a client already has a large React Native codebase, we maintain it rather than rewrite. If a project needs deep platform-specific features on day one (custom camera pipelines, ARKit-specific features), native might be the right call. For everything else: Flutter.