Flutter web in 2026 — is it production-ready?
After 5 years of Flutter in production and one in-house Flutter web product (Table Online), an honest assessment: when Flutter web is the right choice, when it isn't, and what edge cases to avoid.
The question comes up in every discovery call with a new client: “I’ve read that Flutter web isn’t production-ready. Is that true?” Short answer: sometimes yes, sometimes no — it depends heavily on the type of application. This article gives you the criteria we use when recommending or discouraging Flutter web for a project.
When Flutter web is the right choice
Internal tools or B2B apps where the audience is narrow, authenticated, and already committed to using the product. Flutter web’s large bundle size doesn’t matter when the user opens the app 8 times a day and caches it from the first visit. This is where Flutter web shines — one codebase for both the desktop tool and the mobile companion.
Products complementary to an existing mobile app — the web version of a Flutter mobile app, shipped in a few weeks reusing 80% of the code. See Table Online — the web version came as practically free bonus once the mobile app was ready.
Interactive dashboards with complex state where Flutter elegantly solves problems React complicates (fluid drag&drop, coordinated animations across many widgets, custom paint).
When Flutter web is NOT the right choice
Marketing sites. And no, it’s not ironic that we say this from our Astro site. Flutter web has a large initial bundle (1-3 MB just runtime), text-as-pixels in CanvasKit mode, complex SEO without prerender infrastructure. For a page you want Google to see and people to share on LinkedIn, static HTML + CSS beats Flutter by a wide margin.
Apps with high anonymous traffic where every new visitor downloads the bundle. A newsroom, a blog, a mass-market e-commerce — Flutter web costs you real conversions through poor LCP.
Products that critically depend on organic SEO from a high volume of pages. Flutter web can be SEO-ed (we’ll write about prerendering with Puppeteer in a future article), but it’s an engineering investment many teams don’t make.
Edge cases to anticipate
- Routing: if you don’t set
setPathUrlStrategy()from the first commit, you’re stuck with/#/fooURLs that break SEO and user experience. - PWA: Flutter’s default service worker caches too aggressively in development. Invest in proper config from the start.
- Web fonts: don’t let Flutter download Roboto. Use
font-display: swapand load fonts via CSS, not pubspec. - Accessibility: CanvasKit mode produces an almost empty DOM — screen readers are stranded. Use the HTML renderer or add
Semantics()aggressively.
Our conclusion
We’ve used Flutter web in production for 4+ years, both for clients and our own products (Table Online being the flagship example). We recommend Flutter web when the value of a single codebase for mobile + web exceeds the cost of first-load performance — that’s in roughly 70% of projects that come to us needing both mobile and web simultaneously.
But not for this site. This site is Astro, precisely because it shouldn’t be Flutter.
Want to discuss whether Flutter (web or mobile) is the right choice for your product? Get in touch.