The “confirm booking” button works in a demonstration, but where is the booking saved? Where does an employee see it? How does a new status reach the customer after the phone app closes? These questions expose the difference between an interface and a complete service people can use every day.
When comparing mobile development proposals, do not assume that “app” automatically includes the backend, administration, hosting and distribution. Some components may already exist in your organization; others may need building. The proposal should explain the boundaries and the owner of each one, so a finished interface is not left waiting for an uncommissioned system.
Trace one journey from the phone to operations
Consider a fictional sports-court booking app. A user chooses a time and sends a request. An employee checks availability and confirms it or proposes an alternative. The user needs to see that result later. Write the journey down and identify the component responsible for each step.
The phone displays times and collects the choice. The backend saves the request and applies agreed rules. The staff dashboard supports review and updates. Add external payment or messaging providers if they form part of the journey. These responsibilities do not all require separate programs, but they do need a visible place in the scope.
A component map to review with the provider
| Component | Clarification required | Suitable acceptance sample |
|---|---|---|
| Phone app | Included operating systems, devices, languages, journeys and states. | Make and follow a booking on two devices in the test list. |
| Backend and data | New or existing service, request storage and authorization rules. | Find the same request after signing out and into another device. |
| Admin dashboard | Staff roles, available actions and exclusions. | An authorized employee updates a booking and the customer sees its status. |
| External integrations | Provider, required accounts, fees and integration boundaries. | Exercise a success and failure using approved test data. |
| Distribution and handover | Store packages, files, accounts and follow-up on review feedback. | A handover package and release record identify submissions and outstanding actions. |
| Post-launch operation | Hosting, monitoring, support, updates and their limits. | Identify who receives and tracks a booking failure report. |
This is a discussion sample, rather than a universal specification. A local tool without accounts or shared data may not need a new backend. Integrating your existing backend may also be preferable to building another one. Ask why an option is proposed and how it affects delivery, rather than buying an extra component because it appears in a table.
An existing backend does not make integration ready
If you already have a system, provide available API documentation, a test environment and permission boundaries without putting access secrets in the proposal document. Ask which functions the APIs actually support, who will add missing capabilities and how both teams will test the connection.
Android's guidance separates user-interface concerns from data, business rules and data sources, which can be local or network-based. This explains why screen count alone cannot estimate the whole job. Updating a booking status may require changes to data, backend behavior and interface together.
Administration needs named users and actions
“A complete control panel” says little. In the court example, can staff close a time slot or only accept requests? Can one branch's employee see other branches? Who corrects an incorrect time? List the essential actions and request test accounts with different roles.
Every operational need does not require a large reporting system at launch. Identify what is necessary for a working day and what can wait. An existing administration system may already provide the required actions. What matters is that operations staff take part in acceptance instead of everyone reviewing only the phone.
Review interrupted connections and intermediate states
Ask what users see if they confirm a request and the connection disappears before the result arrives. Should they retry, and could that create a duplicate? Do not request an undefined promise that the app “works offline”. Specify what can be read, saved or sent later, and agree how the app explains those states.
Also try an expired login session, a changed permission and a previously displayed slot that is no longer available. A short presentation video cannot settle these cases. Record the required behavior before handover so the discussion addresses a specific action rather than a general feeling of incompleteness.
Distribution has inputs and responsibilities
Apple's review guidance requires a complete app, accessible backend services and the information needed to test it. Ask who prepares accounts, descriptions, screenshots, privacy information and the test build. Establish who handles feedback and which corrections are included. Submitting a package is not a guarantee of approval or a promise about the store's decision date.
The provider should also check the current requirements of any other distribution channel you choose. Separate account and service charges from development fees. Agree how your organization accesses accounts, project files and operational information. Do not wait until completion to discover that the owner cannot manage the release.
Accept a complete journey
Make a test booking on the phone, review it in the employee dashboard and follow the result after reopening the app. Record versions, devices, accounts and results. A complete journey lets you locate gaps instead of blaming the entire app for a problem that may belong to an external service.
For broader planning, see the mobile app budget guide. For screen deliverables, read the UI/UX proposal review. When commissioning mobile app development, attach the component map and the journey you will use for acceptance.
Sources
Opened on 3 November 2026: Android's data-layer guidance and Apple's App Review Guidelines. The example and acceptance map are illustrative, not a client app or a store-approval guarantee. The content was prepared with AI assistance and review of its meaning and sources.