Flutter app development: where it wins, where it costs you, and what it actually costs

Two questions decide most mobile projects: which framework, and what will it cost. This is the honest version of both answers, from a team that ships in Flutter and has also maintained React Native and native codebases.

Where Flutter actually wins#

Flutter renders its own widgets to a canvas rather than mapping to the platform’s native components. That single design decision explains almost every practical difference you will experience.

Your app looks identical on both platforms. Because Flutter draws everything itself, a screen is pixel-identical on iOS and Android. If you are building a branded product where design consistency matters, this removes an entire category of bug reports.

One codebase genuinely means one codebase. In practice React Native projects accumulate platform-specific branches. Flutter projects do too, but far less.

Animation is cheap. The rendering model makes complex animation straightforward rather than a performance negotiation.

Where Flutter costs you#

An honest list, because the framework’s advocates rarely give one:

• App size. Flutter ships its rendering engine. Expect a larger baseline download than an equivalent native app. On modern devices this rarely matters; in markets with expensive data, it does.
• Platform features lag. When Apple ships something new at WWDC, native gets it immediately, Flutter gets it when a plugin catches up. If you depend on brand-new OS features, this is a real constraint.
• Dart is a smaller hiring pool. Fewer developers know Dart than JavaScript. If you plan to hire in-house later, that is a genuine consideration.
• Heavy native integration. Deep Bluetooth work, advanced camera pipelines, or complex background processing mean writing platform channels — and at that point some of the cross-platform saving disappears.

When we would tell you to choose something else#

We build in Flutter and we will still say no to it in these cases:

• Your team already knows React well. React Native lets them ship now instead of learning Dart. Team familiarity usually beats framework merit.
• You are building one platform only, forever. If it is genuinely iOS-only, native Swift is simpler and better supported.
• The app is fundamentally a website. Plenty of “apps” are content in a shell. A progressive web app costs a fraction and skips app review entirely.
• You need cutting-edge hardware access. AR, advanced ML on device, unusual sensors — go native.

What mobile development actually costs#

Anyone quoting a number before understanding your app is guessing. But the ranges are real, and the variables are knowable.

What drives the number#

1. Screens and flows. Not screen count — flow complexity. One screen with conditional states can cost more than five static ones.
2. Backend. Does one exist? Building an API alongside the app often doubles scope.
3. Accounts and payments. Auth, roles, subscriptions and refunds carry compliance and edge cases far beyond the happy path.
4. Real-time anything. Chat, live tracking, collaborative editing — each is a significant multiplier.
5. Integrations. Every third-party system is an unknown until you have read its documentation and hit its limits.
6. Compliance. Healthcare and finance carry audit and data-handling requirements that change how you build, not just what you build.

Rough shapes#

Speaking in weeks of senior engineering rather than dollars, because rates vary by an order of magnitude across markets:

• MVP, existing backend — 6–10 weeks. One platform-agnostic Flutter build, core flow only, deliberately narrow.
• MVP, backend included — 12–18 weeks. API, database, auth, admin.
• Production app with accounts and payments — 20–30 weeks.
• Regulated or real-time product — 30 weeks and up, and estimate in phases rather than one number.

Multiply by your team’s blended weekly rate. A quote far below these ranges usually means the scope was not understood, and you will meet the difference later as change requests.

The question that saves the most money#

Not “which framework” — “what can we remove and still learn what we need?”

Most first versions are two to three times larger than they need to be. Every feature you defer is engineering weeks saved, a shorter path to real users, and one less thing to rewrite when those users tell you your assumptions were wrong.

The best mobile projects we have worked on shipped embarrassingly small and grew from evidence. The worst launched complete, polished, and slightly wrong in ways nobody could discover until it was expensive to change.

Questions worth asking any agency#

Including us:

• Who owns the code and the accounts? (Correct answer: you, from day one.)
• What happens if we stop working together in month three?
• Which parts of the estimate are you least confident about, and why?
• Can we speak to the engineers who would do the work, not just the salesperson?
• What would you remove from this scope if it were your money?

The last one is the most revealing. An agency that cannot name anything worth cutting is optimising for invoice size, not for your outcome.