The customer app is often the first thing a founder can picture. It is where people sign up, browse and place an order. But those screens depend on decisions and work elsewhere in the business. We plan that supporting workflow before treating the app as a complete product.

List the roles before the screens

Write down everyone who touches a request, order or account. In a marketplace, that may include customers, vendors and support. A delivery product may add drivers and dispatchers. A SaaS app may need account administrators and an internal operations team.

For each role, ask what they need to see, what they can change and what happens next. This identifies the surfaces the business actually needs:

  • A customer app for the main user journey.
  • A partner or vendor portal for managing their part of the service.
  • A field app where assignments and proof happen away from a desk.
  • An admin portal for users, content, pricing and exceptions.
  • A backend connecting permissions, notifications, integrations and records.

The list is a planning tool, not a requirement to build five applications. Some roles can share a surface, and some tasks can remain manual during an initial release. The important part is knowing who will do the work.

Choose a complete first journey

Define one useful thing a customer should be able to finish. Then trace the supporting work from beginning to end. If the app accepts an order, someone must be able to fulfil it, handle a problem and answer a status question. A polished checkout cannot compensate for an order that nobody can process.

We separate the essentials for that journey from features that can follow. This helps keep the first version focused while preserving the operational support it needs. Scope decisions should be visible so that a deferred feature does not become an unexpected gap at launch.

Design the decisions behind the interface

Before development, settle the rules that affect several screens. Who can change a booking? Which events trigger a notification? What happens if a payment is incomplete? What does support need to see? These are product decisions as much as backend decisions.

We also look at where the app hands off to another service. Payment, delivery and account integrations should have clear success and failure behaviour. The user needs an understandable next step when a dependency does not respond as expected.

Test the operation alongside the app

Review the first release with the people who will administer it. Run through a new account, the main customer action and an exception. Check that the team can locate the relevant record and take the next action without asking an engineer to change data.

For an initial conversation, bring the target user, the action they need to complete and the list of people supporting it. Our web and mobile services cover the connected product, and our work shows examples across commerce and operations.