A useful mobile app is usually one client of a larger system: APIs provide data and actions, a backend enforces rules, and administrators manage what users cannot see.
The app is not the database
The device presents an experience and may cache limited data. Shared records and authoritative business rules normally live on protected backend services.
APIs define the contract
An API specifies what the app can request, what it must provide and how failures are reported. A stable contract lets mobile and backend work evolve responsibly.
Identity and permissions matter early
Accounts, roles, device sessions and recovery affect architecture. They should not be bolted on after sensitive workflows are built.
Administration completes the product
Content, customer support, exception handling and configuration need operational interfaces. A mobile product without administration creates manual work somewhere else.
A practical checklist
- Name the outcome in plain language.
- Map the current people, responsibilities and exceptions.
- Separate evidence from assumptions.
- Make ownership, cost and operating risk visible.
- Choose the smallest next step that reduces a material unknown.
What to bring to a first discussion
Bring one real example of the workflow, the people involved, the constraint you feel most often and what a useful outcome would change. You do not need a finished specification.
For direct help with this decision, see Mobile applications connected to the complete system behind them.