Native Android vs Flutter for a new business application

When a founder asks “should this be Flutter?”, they are usually asking three different questions: how fast can we show a demo, how well will it behave on real devices, and how painful will the next two years of store releases be.

Flutter earns its place when the interface is the product, both platforms must ship together, and the device features you need are well supported. A field camera, reliable background location, OEM-specific media capture, or a Play-only first release often argue the other way.

On Android we still reach for Kotlin when the application is the camera, the recorder, or the offline ledger. Those are not theoretical preferences — Treasure, MapSeal, Recora, and Sudoku were built as native Android products because the job of the app sits on the device, not in a shared widget tree.

A practical way to decide:

1. Write down the three device capabilities the application cannot live without.

2. Check those capabilities on the exact Android and iOS versions your users have, not on a flagship demo phone.

3. If both platforms are required in month one *and* the risky capabilities are ordinary (lists, forms, accounts), Flutter is in play.

4. If Android is the first market and the risky capabilities are cameras, sensors, or background work, start native. You can still add iOS later with open eyes.

The expensive mistake is picking a stack because it sounds modern, then spending the project on platform gaps. Pick the constraints first. The framework is a consequence.