In this article
A dispatch platform has drivers, dispatchers and managers. A field service product has technicians, supervisors and customers. A marketplace has buyers, sellers and administrators. Each group needs different screens, different permissions and a different idea of what the app is for. The question that comes up in every one of these projects is whether to build one app or several. Our answer is usually one app, and this article explains how we structure it so that it does not become three apps wearing a trench coat.
Why one codebase
Separate apps per role multiply everything: builds, store listings, release schedules, test matrices and the bugs that appear when the driver app and the dispatcher app disagree about what a job looks like. A single codebase shares the data model, the API client, the authentication flow and the design system, and a change to the definition of a job reaches every role in one release. The multi-role dispatch platform we built serves drivers, dispatchers and administrators from one codebase, and the automotive field operations app works the same way.
The exceptions are real but rare. If one role is the public and another is staff, with very different security requirements and store listings, two apps may be cleaner. If a role needs a tablet-only layout that shares almost nothing with the phone experience, the same applies. Everything else is one app.
Roles are data, not builds
The role comes from the server at login, along with the permissions attached to it. The app does not know at compile time which role it will serve. This allows one person to hold two roles, allows roles to change without a release, and prevents the situation where a permission check exists in the app but not in the API. The API is the authority on what a user may do. The app reads the same permissions to decide what to show.
Navigation per role
Each role gets its own navigation tree: its own tab bar, its own home screen and its own set of reachable screens. The tree is chosen after login from the role data. Screens that several roles share, such as a job detail view, are written once and accept the role as context, so a driver sees the actions a driver may take and a dispatcher sees reassignment controls on the same screen. Screens with nothing in common across roles are simply separate screens. Resist the temptation to build one giant screen with every control hidden behind conditions. It becomes impossible to test.
Permissions in one place
A permission helper answers questions such as "can this user reassign a job" in exactly one place, from the permissions the server provided. Screens call the helper and never inspect the role name directly. When a client later adds a supervisor role that can do most of what a dispatcher does, the change is a new permission set on the server, not a search through the codebase for every place the word "dispatcher" appears.
Data each role may see
Role-based filtering belongs on the server. A driver's job list request returns that driver's jobs, and the app does not receive and then hide the others. For offline-capable roles, which in field apps is usually the people in the field, the local database holds only the data that role may see, and the sync layer is role-aware. This helps both security and for the size of what has to be synchronised over a poor connection.
Testing by role
Each role gets its own test accounts, its own test plan and its own set of automated screen tests, because a change made for one role must be verified against the others. Role-switching during development should be a single action, so engineers can reproduce an issue as a driver and then as a dispatcher without logging out and in.
Notifications
Different roles care about different events, and a notification that is useful to a dispatcher is noise to a driver. Notification rules are defined per role on the server, and the app registers its device once with the role attached, so the server can target by role without the app containing any of the logic.
What this costs
A multi-role app takes longer than a single-role app, mostly in design, navigation and testing rather than in the shared core. In our estimates each additional role adds roughly a quarter to a third of the base effort, depending on how much of the experience it shares. That is still far less than a second app.
If your product has more than one kind of user, the questions above are a good start for a scoping conversation. Our mobile app development and React Native pages describe how we build these products, and scoping is free.