Most of what we build is Flutter, and most articles about Flutter are written by people who sell it. This one is about the other side: the products where Flutter adds cost or risk instead of saving it, what we would recommend instead, and the requirements that sound like dealbreakers but are not.

Flutter is the wrong choice when most of the product lives outside the app screen, such as watch apps, home screen widgets or car integrations; when the product is a 3D game or an augmented reality experience; when it is mainly a web product that must rank in search; when you already have a strong native or React team; and when the app must match a brand new iOS or Android design on the day it ships. Hardware access, payments, background location and offline work are not reasons to avoid Flutter, because native code can be added where needed.
A technology recommendation is only worth something if it can come out negative. We build most of our client products in Flutter because, for the typical business app, one codebase for iOS and Android saves real money and time. That argument stops working in a handful of situations, and it is cheaper for everyone to say so before a contract than to discover it in month four.
The cases below are the ones where we would tell a client to use something else, or to use Flutter only for part of the product. Each one names the better fit, so the article is useful even if you never talk to us.
Home screen widgets, Apple Watch apps, lock screen Live Activities, CarPlay and Android Auto are built with native frameworks on each platform, whatever the main app is written in. Flutter does not target watchOS at all. If these surfaces are the product rather than an extra, a Flutter core adds a layer without removing the native work.
Flutter draws interfaces very well and handles light 2D games. Real time 3D scenes, physics and camera based augmented reality need a game engine or the native AR frameworks, where the tooling, performance and community are years ahead.
Flutter can build for the web, and it works well for app like tools behind a login. It renders to a canvas rather than to ordinary HTML, which makes it a poor fit for content sites, blogs, marketplaces with public listings or anything that depends on search traffic.
If your company runs a mature iOS and Android team and a large native codebase, introducing Flutter means a new language, a new build setup and a period of lower output. Flutter can be added to one screen of an existing app, but that mix is harder to maintain than either approach alone.
When the web product is React and the team writes TypeScript every day, React Native lets the same people work on mobile and share logic and tooling with the web app. That shared knowledge is often worth more than the differences between the two frameworks.
Native apps get a new iOS or Android design language through the platform SDK. Flutter draws its own widgets, so a new platform look has to be rebuilt in Flutter and can arrive later. For most business apps with their own brand this does not matter. For an app whose selling point is looking exactly like the latest system, it does.
There is also a seventh case that is not about technology. If the idea can be tested with a responsive website that users open in a browser, building any mobile app first may be premature. Our guide to MVP app features covers how to decide what a first version needs.
The question is not whether Flutter can do something. It is whether Flutter is the shortest path to it. For most business apps the answer is yes, and for a few it is clearly no.
Several concerns come up on almost every first call, and in our experience none of them is a reason to avoid Flutter on its own. Each is solved by writing a small amount of native code where the product needs it.

Before recommending a stack, we ask four questions. The answers usually settle it within the first conversation.
When the answers point to Flutter, we build it as a Flutter app development company and add native code only where the product needs it. When they point to React Native, our React Native team takes the project. When they point to fully native development or a game engine, we say so and help you find the right partner.
If you are still comparing the two cross platform options, the detailed comparison is in Flutter vs React Native for business apps.
When most of the product lives in widgets, watch apps or car integrations, when it is a 3D game or an augmented reality experience, when it is a web product that must rank in search, when your team is already strong in native or React, or when the app must match a new OS design on the day it ships.
Yes. Flutter calls native iOS and Android code through platform channels, so any platform API is reachable. Many features are covered by existing packages, and the rest need a small amount of Swift or Kotlin.
No. Flutter does not target watchOS, so an Apple Watch app is built natively in Swift, even when the main iPhone app is written in Flutter.
For app like tools behind a login, yes. For content sites and public pages that depend on search traffic, a web framework that renders ordinary HTML is the better choice.
For typical business apps, users cannot tell the difference. Performance limits show up in 3D graphics and heavy real time rendering, which are better served by game engines or native code.
Both ship iOS and Android from one codebase. React Native usually wins when your team already works in React and TypeScript. Flutter usually wins for custom interfaces and when no existing team sets the direction.

Thomas sets the company's long term strategy and direction, identifies market opportunities, and owns business development and client acquisition. He builds strategic partnerships that last beyond a single project. He works with clients from the first strategy conversation, so their business goals, not just their feature list, drive every decision.
Describe what you are building and where your users will spend their time. You will get a straight answer on the right stack, even when it is not Flutter.
30 minutes, no preparation needed.