How to Plan a Mobile App Before Development

Commissioning a mobile app without a workflow is how you get a gallery of screens and a backend that cannot support them. Palmate Solutions treats mobile app development as product work: who uses the app, how often, what happens when the network drops, and which APIs already run the business. UI comes after that, not before.

This guide is the planning sequence we want clients to complete — or to hire us to complete — before a pixel-perfect set of mockups becomes a hostage.

Start with jobs, not platforms

Write jobs-to-be-done in sentences a field supervisor would recognise:

• “Warehouse picker confirms a pick list and flags a shortage before the van leaves.”
• “Salesperson records an order at a retailer with patchy 4G and needs it to queue.”
• “Customer checks order status and downloads an invoice.”

If the job is “browse the marketing site on a phone,” you may want a responsive website, not an app. Store listing fees, update cadence, and OS permission prompts are a real tax. An app is justified when the job needs camera, offline queues, push, or a native-feeling companion to an existing product.

Name roles. A picker, a manager, and a customer are three products that happen to share a codebase. Permissions, navigation, and success metrics differ. Collapsing them into one “user” is how you ship a cluttered home screen.

If the app is really an internal console, the same discipline as planning an internal dashboard applies: operational screens, not marketing pages.

Decide what v1 will not do

A release thesis is a list of cuts. Examples:

• v1: pick confirmation and shortage flags. Not: full WMS, returns, and payroll.
• v1: order status and invoices. Not: in-app chat and a loyalty game.
• v1: Android-first if that is the device fleet, with iOS when the job exists there.

“Both stores, every feature, parity with the website, plus offline” is a programme. Treat it as one only if you have the budget and an owner. Otherwise you will slip dates by discovering scope in QA.

Write success as observable behaviour: time to complete a pick, orders submitted without a desktop, support tickets about “I cannot see stock.” Vanity metrics (downloads) do not tell you if the job is done.

Network, devices, and offline are product features

Ask:

• What devices exist today (age, OS version, shared logins)?
• Is the app used in a basement, a mandi, a truck, or a broadband office?
• Which actions must succeed offline and sync later? Which must refuse to proceed without a live confirmation (payments, stock reservations)?

Offline is not “cache the last JSON and hope.” It is a queue with conflict rules: last-write-wins is wrong for inventory; “server is authority, device is a proposal” is often right. If you skip this, you will debug duplicate orders after the first festival weekend.

Battery, camera quality, and storage for photos of damaged cartons are constraints. Designers who only mock iPhone Pro on Wi-Fi will miss them.

The backend will make or break the app

Mobile clients expose problems a website hid: pagination, token refresh, file uploads, and push payloads. If your API was built for a server-rendered admin, it may not survive a flaky radio.

Plan API integration as part of the app, not a follow-on. You need:

• Auth that can refresh without kicking the user every hour in a warehouse.
• Pagination and filters the UI can actually use (cursors beat giant pages).
• Idempotent POSTs for “submit order” so a retry does not double-book.
• Error shapes the app can show (“reservation expired”) rather than a generic 500.
• A push story: who sends, what the payload contains, what happens if the user taps.

Use the API project estimator to count systems and directions of data before you assume “we already have an API.” Many businesses have an API that cannot support a mobile client without work.

If you do not own the backend, write the contract first (OpenAPI, examples, sandbox). UI without a contract is fiction.

Choose a stack after the product, not before

Palmate uses Flutter as a default when a single codebase can honestly serve iOS and Android. That is a fit question, not a religion. Native modules, a PWA, or a well-built responsive web app are better when the job is browser-shaped or you need a platform API Flutter cannot reach cleanly.

Read Flutter vs React Native vs native for the comparison. Do not pick a stack because a freelancer already knows it, then discover you needed background location and a specific OEM’s BLE stack.

Release operations are in the plan

Apple and Google are part of the critical path:

• Developer accounts, legal entity, tax forms.
• Signing, bundle IDs, package names.
• Privacy questionnaires, data safety forms, permission copy.
• Crash reporting, staged rollouts, a way to ship a hotfix.
• Push certificate or FCM setup that survives staff turnover.

Treat TestFlight and Play Console handover as deliverables. Discovering them at submission time is how launches slip by two weeks for paperwork.

A planning artefact we actually use

Before development, you should be able to hand an engineer:

1. Roles and jobs, with frequency and environment.
2. v1 / later split, including explicit non-goals.
3. Device and offline matrix.
4. API contract or a funded API workstream.
5. Analytics and crash tools, plus who reads them.
6. Store listing owner and privacy copy owner.
7. A named product owner who can answer policy questions in a day, not a month.

If item 7 is missing, pause. Engineering cannot invent your refund rule or your discount authority.

How Palmate runs discovery

Our mobile app discovery is user roles, offline needs, device inventory, and a release thesis. We will recommend not building an app if a website or a tightened internal dashboard is the honest v1.

Planning is successful when a developer can implement a vertical slice — one job, real API, real device — without a meeting to decode the mockups. If you cannot describe that slice, you are not ready to develop. You are ready to keep planning, and that is cheaper than rebuilding the navigation three times.