Native and cross-platform development are ways to build an experience, not reliable shortcuts to a good one. For a small business, the important question is whether the chosen approach can deliver its hardest workflow predictably. Comparing generic feature lists rarely answers that. A better exercise is to choose the screen where camera use, offline work, animation or accessibility creates the greatest uncertainty.
Prototype the uncomfortable part
Imagine a regional repair company whose technicians photograph faults, annotate an image and attach it to an offline job. A prototype containing only login and a job list says little about the demanding part. Ask the team to demonstrate image capture, rotation, interruption by a call, local saving and reopening on representative phones. Include large text and screen-reader operation. Flutter's platform integration guidance illustrates that shared frameworks still need to interact with platform services. Treat those boundaries as things to demonstrate, rather than assumptions hidden in an estimate.
Compare the ongoing shape of the work
A shared codebase may help keep business behaviour consistent across platforms. Native implementations may offer a more direct route to platform-specific capabilities. Neither statement settles the decision for your app. List which screens can comfortably share behaviour and which features need special platform handling. Ask how a future operating-system change would be investigated, how third-party packages are selected, and who can maintain custom integrations. The answer should describe responsibility and evidence, not simply the framework's popularity or the number of developers who use it.
Choose a reviewable tradeoff
Create a short decision record with the working prototype, supported devices, known limitations and the reason for the choice. Include what would trigger a reconsideration: an unsupported scanner, unacceptable accessibility behaviour, or a new product direction. Resist promising identical pixels when familiar platform interaction would be clearer. The useful goal is consistent task outcomes with appropriate device behaviour. Keep the prototype available as a regression scenario during delivery, so the capability that justified the architecture continues to work as the app becomes more complex.
- Which feature is least like a standard form or list?
- Has that feature been exercised on both target operating systems?
- Where does shared code end and platform-specific responsibility begin?
- Can another developer explain and maintain the chosen integration after handover?