React or Flutter for your first app?
A founder-friendly look at when a cross-platform Flutter app beats a web-first React build — and when it doesn’t — based on what we reach for and why.
We get asked this in nearly every first call, usually phrased as if there’s a right answer waiting to be looked up. There isn’t. But there is a way we decide, and it has very little to do with which technology is “better” and almost everything to do with who your users are and what you’re trying to learn.
First, a quick definition, because the question usually hides a second one. React on the web gets you something that runs in any browser, instantly, from a link — no install. Flutter gets you a single codebase that compiles to genuine iOS and Android apps people download from the stores. React Native sits in between, but for a first build the real fork is almost always web-first versus app-first, so that’s the one we’ll focus on.
Start with where your users already are
Before anything technical, we ask how someone will first hear about you and what they’ll be doing when they do. A person who discovers you through a search result, a tweet, or a link in a newsletter wants to click and be using it one second later. That’s the web’s home turf — no install, no store listing, no friction. Forcing those people to download an app is asking them to clear a hurdle most of them simply won’t.
But if the heart of your product is something people return to several times a day, or it leans on the phone itself — the camera, push notifications, location, working offline, payments that need to feel native — then an installed app stops being a hurdle and becomes the point. A home-screen icon is a standing invitation to come back.
When web-first React wins
We reach for a web build when the priority is reach and speed of iteration. It’s the fastest way to get something in front of strangers, the easiest thing in the world to share, and the simplest to update — you push a fix and everyone has it immediately, with no review queue between you and your users. For most marketplaces, dashboards, internal tools, and anything you’re still actively figuring out, that iteration speed is worth more than native polish.
It’s also the cheaper place to be wrong, which in an MVP is most of the job.
When Flutter wins
We reach for Flutter when the experience genuinely lives on the phone and you want both platforms without building — and maintaining — two separate native apps. One team, one codebase, two stores. For consumer products where people expect smooth, app-like motion and deep use of device features, Flutter gets you very close to native feel without doubling the work.
The catch worth saying out loud: shipping to the App Store and Play Store adds real overhead — review times, store accounts, a release process — that the web simply doesn’t have. It’s manageable, but it isn’t free, and it’s worth pricing in before you commit.
The best stack for a first version is the one that gets you to real feedback with the least ceremony.
The thing nobody tells you
Whatever you pick, you’re also picking what you’ll maintain, hire for, and live inside for the next couple of years. A second platform isn’t twice the features — it’s twice the surface area for bugs, twice the testing, twice the release work, forever. That’s the strongest argument for choosing one place, doing it well, and only expanding once the product has earned it.
It’s also why we push back hard on “let’s do web and iOS and Android at launch.” That’s three products. You have more than enough to prove with one.
How we’d actually decide
Stripped right down, our rule of thumb looks like this:
- Discovery is a link, usage is occasional → web-first with React. Lowest friction, fastest to iterate.
- Usage is daily and leans on the device → Flutter, so you get both app stores from one codebase.
- You genuinely don’t know yet → build the web version. It’s cheaper to change your mind from, and it can validate the idea before you commit to a store presence.
None of this is permanent. Plenty of products start as a web app to find their audience and add a native app once they know exactly who it’s for and what it needs to do. Starting on the web doesn’t close the door to Flutter later — it just keeps you from paying for two front doors before anyone has walked through the first.
That's the work we do every day. Tell us what you're shipping.