Notes Mobile
What to decide before you build a mobile app
A mobile app is easy to want and expensive to regret. The regret usually isn’t the technology. It’s launching without a crisp job for the app to do, or building “everything” before anyone uses anything. These are the decisions worth locking before kickoff.
01 Who holds the phone, and why today?
Write one sentence: “This app helps [person] do [job] when [context].” If you need three audiences and five jobs on day one, you don’t have a version one yet. You have a roadmap wearing a launch costume.
Field teams, customers, and managers rarely share the same screen needs. Pick the group that creates the most operational pain when the job is slow or offline, and serve them first.
02 Must it work with bad signal?
In South Africa (and plenty of industrial sites worldwide), offline or flaky connectivity is a product requirement, not an edge case. If people capture jobs, photos, signatures, or stock counts away from Wi-Fi, say so early. Offline sync changes architecture, testing, and timeline more than almost any UI preference.
03 Native app, or a sharp mobile web experience?
Choose native or cross-platform apps when you need store distribution, device sensors, push that users rely on, or a repeatedly opened tool that deserves a home-screen icon.
Choose a well-built mobile web app when the job is occasional, the audience resists installs, or content and forms dominate. Many “app ideas” are really responsive web products with a login.
Many “app ideas” are really responsive web products with a login. Decide the job before you decide the store listing.
04 What systems does it talk to?
List the sources of truth: ERP, CRM, accounting, WhatsApp workflows, spreadsheets that refuse to die. An app that can’t read or write the real data becomes a second admin job. Integrations are not a phase after design. They shape the design.
05 What does version one exclude on purpose?
A strong v1 is embarrassing in its focus. Examples of healthy cuts: one role only, one primary workflow, admin on the web first, reporting as exports before fancy dashboards. Write the cut list down. It protects budget when new ideas arrive mid-build (they will).
06 Who owns content, support, and updates after launch?
Apps need store listings, crash monitoring, OS updates, and someone who answers “the button does nothing.” Decide who that is before you celebrate launch day. Care is part of the product, not an optional retainer joke.
07 A kickoff pack that makes builds faster
- One-sentence job story and primary user
- Must-have offline / online rules
- Screens or paper forms people use today
- Systems to connect, with access contacts
- Explicit v1 cut list
- Success metric for the first 90 days
Bring that pack to a project chat and we’ll tell you whether you need a native app, a mobile web product, or something smaller that ships sooner. For operations software choices, see ERP vs custom software.