Flutter is still the right call (for Nepal)

the local optimum

There's a particular shape of project that comes up a lot in Nepal. A small team — maybe three engineers, maybe five — needs to ship two mobile apps (iOS + Android), an admin dashboard, and a marketing site. Funding is tight. Time-to-market is everything. The team is more JavaScript-leaning than Swift-Kotlin-leaning because the local talent pool slants that way.

For this shape of team, Flutter is still the right call. Not React Native, not native-per-platform, not "Swift+Kotlin Multiplatform Mobile." Flutter.

The reason most people miss is hiring math.

the React Native pull

The default answer in 2026 for "we need an iOS and Android app" is React Native. It's the answer because:

• The team probably writes React for the web.
• React Native lets them reuse JSX patterns and hooks.
• Expo has gotten genuinely good — npx create-expo-app produces something shippable.
• React Native is what the JS ecosystem produces, so package availability is great.

These are real benefits. I've shipped React Native apps. I'd choose it for some teams.

But for the specific shape above — small team in Nepal, two apps + admin + site, wants to grow — there are problems that don't show up until month four:

Build complexity. React Native's native build steps still go wrong in non-trivial ways. EAS Build helps; it doesn't eliminate the surface area. When something breaks, the fix is in Xcode or in a Gradle file, and your JS-first team isn't fluent there. You burn a day every month on this.

Two engines, one debugger. When a bug straddles the JS bridge and native code, you have to understand both halves. The skills don't compound — debugging the JS side and debugging the native side are different exercises. For a team that's iterating fast, this is a tax.

Performance ceilings. React Native has gotten faster, especially with the new architecture. But for animation-heavy or list-heavy apps, you eventually hit cases where the bridge is the bottleneck. Workarounds exist (re-implement in native, use Reanimated, drop to JSI), all of which cost more time than the framework was supposed to save.

what Flutter gives this team

Flutter's pitch is unfashionable in 2026. Dart isn't the cool language; "rendering its own UI" sounds heavy; the bundle sizes are larger than RN. None of these are wrong — but for the small-team-in-Nepal case they're the wrong things to optimize for.

What Flutter actually does well:

One language, one runtime. Dart is the only language. The same language runs the iOS app, the Android app, the macOS app if you want one, and increasingly the web. There's no bridge. There's no "native side." When something is slow, you profile one runtime.

A consistent UI primitive. A Container is a Container everywhere. A Row is a Row. The mental model is small and survives every platform. The team that knows it deeply for iOS knows it for Android automatically — no separate dive.

Hot reload that actually works. State is preserved across reload. You can iterate on UI in a tight loop that React Native doesn't quite match. For early-stage products that's gold.

Tooling that doesn't fight you. flutter doctor catches setup issues that would otherwise take half a day. The build pipeline (flutter build apk, flutter build ipa) is a single command that produces a real artifact. No EAS, no Fastlane, no separate CI per-platform.

The plugin ecosystem is enough. People will tell you Flutter has fewer packages than RN. True, but for a normal mobile app — auth, networking, local storage, image picking, push notifications, deep links, in-app purchases — the official pub.dev packages are mature and maintained.

the hiring math

Here's the part most analyses miss.

In Pokhara, in 2026, you can find:

• Front-end JS engineers: lots. Easy to hire.
• Native iOS/Android engineers: very few. Expensive.
• React Native engineers: some, but most are JS engineers who picked up RN, not RN-first engineers. They're good for the JS half and weaker for the native half.
• Flutter engineers: a real and growing pool. The Nepali Flutter community is unusually active — there are real meetups, real workshops, real bootcamp output.

For the small team, this means:

• React Native: you hire JS engineers. They struggle with the native half. You either accept that struggle or hire a senior native engineer (expensive, hard to find) to backstop.
• Flutter: you hire Flutter engineers. They know the framework end-to-end. The struggle isn't there.

The framework with the fewer packages but the better local hiring market wins for a five-engineer team in Pokhara that needs to ship in three months.

what you give up

Honest list of Flutter trade-offs:

• Bundle size. Flutter apps are 10–15 MB minimum because they ship the rendering engine. For some markets this matters; for most apps in Nepal where users are on Wi-Fi, it doesn't.
• Look-and-feel concerns. Flutter draws its own widgets, so a Cupertino UI doesn't quite match iOS native exactly. This bothers some product managers more than it should. Material You looks great.
• The web target is half-baked. Flutter for web exists. It's not as good as a real web framework. Don't use Flutter for the marketing site; use Next.js. Use Flutter only where you're using Flutter.

For the small team, none of these are dealbreakers.

the integration shape that works

For the typical Pokhara stack:

• iOS + Android app: Flutter, single codebase.
• Admin dashboard: Next.js + React Server Components + a typed API (probably tRPC or NestJS).
• Marketing site: Next.js. Static. Cheap to host.
• Backend: NestJS + Postgres + Redis. Or Cloud Run + Firestore if the team prefers managed.

Three codebases, three engineers can ship them, the languages don't fight each other (Dart + TypeScript, both type-safe, both modern), and the team can hire from a real local pool.

The naive "everything in TypeScript via React Native + Next.js" sounds tempting on paper. In practice, the team that does it spends month four debugging Xcode build issues, hires a contractor to backstop, and the savings evaporate.

what's coming

Flutter's next round of improvements (Impeller renderer fully shipped, better DevTools, the Skia → Impeller migration done) makes the case stronger, not weaker. Dart 3's pattern matching and macros (in beta) make the language genuinely competitive with TypeScript for the small surface most app code uses.

I expect to keep recommending Flutter for this exact team shape for at least another two years.

the meta-point

Framework decisions look like technical decisions. They're mostly hiring decisions. The right framework is the one you can hire for in your market, that produces engineers who can do the whole job rather than half of it.

For a small team in Nepal shipping mobile + admin + marketing on a tight budget: Flutter for the apps, Next.js for the web, NestJS for the API. That's it. Resist the React Native default. The hiring math doesn't support it here.