Back to notes
July 27, 20266 min read

Why Flutter (and not React Native) for VantFi

A technical decision with concrete criteria: why I chose Flutter over React Native to build VantFi as a solo founder with prior JavaScript experience.

flutterstack-decisionsvantfi

The most frequent question I get about VantFi is why Flutter, given that the rest of my stack is JavaScript/TypeScript. It would make sense to pick React Native to reuse knowledge, libraries, and mental model. But I didn't. Here's the decision and the criteria.

The criterion that weighed most: perceived performance

VantFi is an app people open 5-10 times a day for 30-second sessions. Perceived speed is everything. If opening the app, logging an expense, and closing it takes more than 3 seconds, we lost.

Flutter compiles to native code (ARM on mobile), no JavaScript bridge. That means opening a screen animation, transitioning between pages, scrolling a list — everything runs at 60-120fps without much thought. React Native has improved a lot with the new architecture (Fabric, Hermes), but there's still a bridge between JavaScript and native, and in intensive operations it shows.

In my test prototype (the same dashboard screen implemented in both), Flutter opened in 280ms cold start; React Native (Hermes) in 510ms. On a mid-range Android (Moto G50), the differences are even more marked. For an app whose selling point is "fast and frictionless", those 230ms matter.

The criterion that hurt to ignore: ecosystem

React Native has Expo, which is a dream. Configure, publish, OTA updates, distribution, prebuilt UI components. For someone coming from web React, feeling at home takes a day.

Flutter has flutter pub, which is functional but less polished. Store distribution is manual (no direct equivalent to EAS Build), you have to learn Gradle and Xcode at least a little, and OTA updates are a gray area (Shorebird exists, but it's not native to the framework).

I weighed this for a week. What ended up deciding it: I prefer to pay the learning cost once (Flutter has an initial curve, but it's stable after) than to pay the performance cost every day.

The hidden criterion: local hiring

In Bogotá, finding a Flutter dev is relatively easy. The Latam Flutter community is active and bootcamps teach it. React Native too, but RN devs tend to come from web and many prefer to stay in web. Flutter devs come from mobile and are specifically mobile.

When VantFi grows and needs hiring, I prefer to look for people who love mobile, not people who tolerate it — and that's a subtle but real cultural difference, one you don't see in a performance benchmark but you do see in how a product gets built over a couple of years.

The criterion that mattered but less: type of UI

Material Design 3 (which Flutter uses by default) has a strong opinion on how an app should look. If you want to follow that opinion, Flutter gives you polished components, consistent transitions, and a coherent look-and-feel effortlessly. For VantFi — a utility app, not a product where branding leads — that's an advantage, not a limitation.

React Native gives you more freedom but also more decisions. Every component you pick (NativeBase, Tamagui, Gluestack, custom). Every style you define. More freedom is good when you have a design team. As a solo founder, freedom is extra work.

What did NOT weigh as much as I expected

Reusing TypeScript from the backend. In practice, almost no backend code is reused on mobile. API types I regenerate via OpenAPI from the backend, I don't import them directly. Sharing language between client and server is nice in stack presentations, but in real code it produces little.

Hot reload. Both frameworks have good hot reload. Flutter is slightly faster in practice (sub-second) but RN is close. Not a real factor.

What I'd change if I were deciding today

Probably the same. But there's a new alternative I'd evaluate carefully: Capacitor + Vue/Svelte + native plugins. For utility apps like VantFi, a webview with native plugins can be enough, and preserves the entire web ecosystem. The reason I didn't pick it is the same perceived-performance one: webviews feel different from a native app, and for an audience that opens the app ten times a day, that adds up.

My general recommendation: if your app is 80% forms and lists, RN or Capacitor are fine. If your app needs to feel fast, animated, and native, Flutter delivers better results for the same effort.