Before you build a mobile app

Installing an app is a meaningful request. The customer gives up storage, accepts another update cycle and may be asked for access to location, photos, notifications or sensors. Reproducing the company website inside a store download is not a fair exchange for that commitment.

The case becomes stronger when the task is frequent and native capability changes it materially: field work that must continue offline, scanning with the camera, location-aware operations or timely alerts tied to an ongoing service. If the experience is occasional, informational and easy to complete in a browser, the web retains important advantages.

Compare an app with a responsive site, progressive web app and improvements to an existing service. A web experience is searchable, linkable and available without a store decision. An installed app becomes compelling when repeated use, offline continuity or native hardware materially shortens the path to value.

Channel choice also affects acquisition. App-store discovery is competitive, installation adds a conversion step and updates depend on platform policies and user behaviour. If most customers complete an occasional informational task, the web may produce a better experience at a lower lifetime cost.

Prototype the core loop before building the surrounding account, settings and content systems. Put it in front of the people expected to use it and observe whether they complete the task without explanation.

Test return behaviour, not only first impressions. A convincing prototype session cannot prove that somebody will keep an app installed. Run a manual or lightweight version of the service long enough to observe frequency, reminders, interruptions and whether the value remains after novelty fades.

The first session must reach useful value quickly. Defer account creation, permissions and profile questions until they are necessary. When a permission is required, explain the feature it enables immediately before the operating-system prompt; asking for camera, location and notifications on launch produces rejection without context.

Plan for interrupted use. Preserve progress when the app backgrounds, make network state visible and let people recover from expired sessions without losing work. Mobile quality is defined as much by these transitions as by the ideal path shown in a design file.

Select native, cross-platform or shared-web technology based on the product's interaction demands, team capability and release horizon. Evaluate accessibility support, performance on lower-end devices, access to required APIs, debugging maturity and the cost of platform-specific exceptions.

The application is only one part of the system. Authentication, APIs, synchronisation, analytics, feature controls and content workflows need ownership too. Define how old versions behave when the backend changes, because unlike a website, not every customer runs the latest release.

Store approval, analytics, crash reporting, accessibility, privacy disclosures and customer support are part of the product. Budgeting only for the first release creates a polished launch followed by slow decline.

If the recurring value is not yet clear, test the service through the web first. Learning that an app is unnecessary is a useful product result.

Agree launch gates for the core task before release pressure takes over: completion rate, crash-free sessions, response time on the minimum supported device, accessibility, support readiness and recovery from interrupted work. A date is useful for coordination. It is not evidence that a product which loses data or excludes essential users is ready.

Once released, installs are the least interesting measure. Track activation, successful task completion and retained use; read store reviews and support cases alongside telemetry. If repeated value does not emerge, simplify the proposition or reconsider the channel. Continuing because the first release was expensive is not a mobile strategy.