The decision to build a mobile app shouldn't be made just to have a presence in the App Store or Google Play. It should be clear which job the user will complete more easily on their phone. If the camera, notifications, or offline mode meet a genuine need, the app's value becomes much clearer.
01Start with a single core scenario
A field worker might be completing a task, a customer might be booking an appointment, or a user might be tracking an order. Plan the first release around that task being completed start to finish. Settle the order of operations before the number of screens. Decide early which data the web and mobile app will share. We covered narrowing the scope of a first release in our MVP article as well.
02Design for what happens when the connection drops
Mobile connectivity isn't always stable. Don't show an action as saved when it hasn't been. Let the user distinguish between pending, sent, and failed actions. It matters that resending the same action doesn't create a duplicate record. Separating data and interface responsibilities supports testability; the Android architecture guide explains this approach.
03Explain permissions at the moment they're needed
Camera, location, or notification permissions should be requested in connection with what the user is doing at that moment. Show an alternative flow when a user declines. Collecting unnecessary permissions doesn't add value to the app. Notifications should also open the correct screen; if the session is closed, context should be preserved after sign-in.
04Test real devices and update scenarios
Build a test plan that covers different screen sizes, OS versions, and weak-connection conditions. Determine how an older app version will behave against a newer server version. Store releases, signing accounts, and update responsibilities should be clear before delivery. In our mobile app service we clarify these responsibilities together at the start of the project.
05Prepare before you start
- The single core scenario the app will solve in its first release
- Target platforms (iOS, Android, or both) and the oldest versions to support
- The actions that need to work offline
- The permissions needed and the reason for each
- Who will own the store developer accounts
- The data and systems shared with the web side
Written by
The Paradigma7 team
Product, engineering and operations
We are an Ankara-based team building software for Europe. Nothing here is theory: these are the processes we actually run on client projects.
About us