“We need an app” sounds like a project brief. Usually, it is the beginning of one. The next question is what someone must accomplish that the current website, process or existing tool cannot handle well. An icon on a home screen is a distribution choice; it is not yet a customer benefit.
A restaurant menu consulted once on holiday, a technician’s daily inspection record and a customer’s monthly booking do not have the same requirements. Choosing a framework before distinguishing those jobs is like choosing a delivery van before checking whether the business sells furniture or postcards.
Write the job in one sentence
Use a concrete format: “This person needs to complete this action, in this situation, with these constraints.” For a fictional maintenance team: “A technician records an inspection in a basement with poor reception and synchronises the result later.” For a fictional salon: “A customer checks available times and books from a link.” These are different problems even if both eventually have a login screen.
Then record frequency, target devices, network conditions, accessibility needs and the consequence of failure. Distinguish a requirement from a preference. “Works on our managed Android devices” is testable. “Must feel premium” needs observable examples before it can guide architecture.
When the web deserves the first prototype
A responsive website or web application is a useful candidate when people arrive through links, search or occasional visits and need information, forms or account tasks. It can avoid making installation a prerequisite for the first useful action. That does not guarantee lower total cost: a complicated web product still has complicated business rules.
A progressive web app can add capabilities such as local data handling and installation. Support depends on the browser, operating system and individual API. The web.dev guidance explicitly calls for feature detection and progressive enhancement. “It is a PWA” is not enough evidence that your exact hardware or background-work requirement will function on every target device. PWA capabilities and support.
Installation also differs across platforms. Test the real route from the invitation link to the first completed task, including people who do not install anything. A successful demonstration on the developer’s phone is one observation, not a compatibility matrix. PWA installation paths.
Where Flutter fits
Flutter supports applications across multiple platforms from a shared codebase. Its documentation also describes platform-specific integrations, plugins and custom native code when needed. That combination can suit products whose Android and iOS experiences share substantial behaviour. It does not remove separate platform testing, permissions, release work or interface adaptation. Flutter platform integration.
Do not assume Flutter is simply a website wrapped in an app. Its architecture and rendering model differ from a conventional webview wrapper. Equally, “one codebase” should not become a promise that every line, dependency or interaction will be identical everywhere. The framework’s own FAQ describes platform services and native interoperability. Flutter FAQ.
Before committing, prototype the hardest integration rather than the easiest login screen. If the product depends on a specific scanner, background task or vendor SDK, test that path on the actual target devices. Check the relevant plugin’s platform coverage, maintenance and failure behaviour. A beautiful empty dashboard proves very little about those risks.
When platform-specific development deserves a closer look
A deeply platform-specific workflow may justify a native implementation: for example, when the essential feature depends heavily on a particular operating-system framework or must follow new platform behaviour closely. That is a reason to investigate, not proof that native is always faster, safer or better. Compare working prototypes against the requirement.
Distribution is another workstream. Apple’s review guidelines include minimum-functionality expectations under section 4.2; putting a website inside a package does not guarantee approval. Store policies, account ownership, review preparation and updates belong in the project scope regardless of how attractive the first build looks. Policies checked on 8 October 2026. Apple App Review Guidelines.
A decision sheet instead of a framework contest
For each candidate, answer five questions: can a new user reach the first useful action; can the essential device feature work; what happens without a network; how are updates distributed; and who maintains it after launch? Mark each answer “demonstrated”, “documented but untested” or “unknown”. An unknown is a task for a prototype, not a reason to invent a confident score.
For the fictional salon, a responsive booking flow is a reasonable first candidate if it satisfies the actual workflow. For the inspection team, local storage, synchronisation and device integration need an early technical experiment; Flutter and native implementations may both be candidates. These are conditional recommendations, not quotations, case studies or evidence that one option is universally cheaper.
An app is worth building when its capabilities and repeated use justify its distribution and maintenance costs. Start with the user’s job, test the risky assumptions and choose the smallest delivery model that does it well. The technology can then earn its place in the proposal, rather than arrive as the answer before anyone has asked the question.