Decide whether an app is the right answer

Custom mobile app development makes sense when the phone is central to a repeated task. Scanning stock, receiving operational alerts, capturing evidence in the field or completing a frequent customer journey can justify a dedicated experience. A business does not automatically need an app because competitors have one.

Start with a responsive website when the job is mainly browsing information or completing an occasional form. Consider an app when the workflow benefits materially from device capabilities, repeated access or carefully designed offline behavior. Compare the whole ownership cost, including updates and support, not just the first build.

A useful brief makes this decision explicit: who uses the app, what they need to complete and why the existing experience is insufficient.

Describe the task from start to finish

Write three to five priority journeys in plain language. For each one, identify the trigger, the information needed, the action taken and the confirmation that proves completion. Include what the user sees when the task cannot be completed.

For example, “a warehouse colleague scans an item, sees the assigned picking quantity, confirms the picked amount and receives a visible response from the ERP” is more useful than “barcode scanner feature.” It reveals dependencies, permissions and exception states.

  • Who is the user, and what access should they have?
  • Which records must be available before the task begins?
  • What device capability is genuinely required?
  • What happens after an invalid scan or interrupted connection?
  • Which business system confirms the final result?
  • How does the user correct a mistake without creating a second transaction?

Make offline behavior a product decision

“Works offline” needs a precise definition. Can users only read previously loaded records, or can they create and change data? Which actions must wait for a connection? What happens if the same record changes elsewhere before synchronization?

Android’s offline first architecture guidance treats local data and synchronization as architectural concerns. In a business brief, translate that into visible states: saved locally, waiting to sync, confirmed by the server and needs attention.

A delivery note stored on the phone is not yet proof that the back office received it. Users should be able to distinguish those states. Decide how pending work survives closing the app, signing out or changing devices, and avoid promising offline support for actions that require live authorization.

Define the integration contract

List the APIs, owners and environments the app depends on. Identify how users sign in, how permissions are checked on the server, and where product, order or customer data originates. Avoid embedding privileged service credentials in the mobile app.

Agree stable identifiers, validation rules, error responses and retry behavior. Repeatedly pressing a button or retrying after a timeout must not create duplicate orders or payments. Separate “request received” from “business action completed” when a backend job is asynchronous.

If the app connects to an ERP, confirm the supported version, hosting model and customization constraints. Our Waslio for Odoo mobile is currently in beta; a bespoke workflow still needs its own scope and compatibility review.

Include privacy and release work in the scope

Inventory the data collected by the app and its third party SDKs. Decide which permissions are essential, how the purpose is explained, and what the experience looks like when permission is declined. Requesting everything on first launch is not a substitute for designing the workflow.

Apple provides App Store Connect guidance on app privacy information. Treat store disclosures as release work that must reflect actual behavior, not generic copy added at the end. Confirm applicable privacy obligations with appropriate advice for your business.

Assign ownership of developer accounts, signing, store listings, support contact details and release approvals. Decide who responds to a store review question and who maintains the app after an operating system update.

Test the conditions people actually work in

Agree a device and operating system test matrix based on your users. Include small screens, larger text, weak connectivity, expired sessions, permission denial, backgrounding and interrupted uploads. Test with realistic data volumes, not only a fresh account containing three records.

For operational tools, ask a real user to complete the task without coaching. Measure completion time, failed attempts and requests for help. For customer apps, follow the whole journey through checkout or enquiry confirmation rather than celebrating a polished home screen.

Plan a limited rollout with monitoring and a support route. Decide which faults block wider release and how you will communicate a temporary workaround.

Send a brief that leads to a useful first conversation

Share the audience, the three most important tasks, existing systems, device requirements, offline expectations and a realistic launch constraint. Add the outcome you want to improve: fewer picking errors, quicker field reporting or a smoother repeat purchase journey.

Ask for a proposal that separates discovery, first release, optional features and ongoing ownership. A clear handover should cover source code access, documentation, environments and maintenance responsibilities.

Tell us about your mobile app idea. We can help decide whether a website, a custom app or a smaller integration solves the actual problem before you commit to the full build.