Your app is actually three apps.

Strategy · 6 min read

A client comes in describing one app. "It connects people who need a service with people who provide it. And I need a way to manage it all from the back end." That sounds like one app. It's three. The consumer experience. The provider experience. The admin dashboard. Three separate sets of screens, three separate user flows, three separate sets of logic. And the budget just tripled.

This is one of the most common surprises in app design. You think you're building one thing, but the moment you start mapping the user flows, you realise each user type needs their own version of the product. They see different screens. They have different goals. They interact with the data differently. That's not a settings toggle. That's a separate application.

The complexity multiplier

A single-user app with fifteen screens is manageable. Add a second user type with their own screens and you're at thirty. Add an admin who needs to manage both user types and you're looking at forty-five screens or more. Each user type needs onboarding, navigation, notifications, settings, and edge case handling. They might share some components, but the flows are different enough that each one requires dedicated design work.

The development cost follows the same curve. More screens means more code. Different user types mean different permission layers, different API endpoints, and different testing requirements. A developer isn't just building one app. They're building three, and making sure they all talk to each other correctly.

I've had projects where this realisation hit during the initial scoping. The client expected one quote and got something much higher. Not because anyone was padding the numbers. Because the scope was genuinely three times larger than what was described in the initial conversation.

How to handle it

The answer isn't to cram everything into one release. It's to pick one user type and build their experience first. Which user type is most critical to proving the concept works? Build that. Get it in front of real users. Validate the core value proposition with one side of the equation before investing in the other sides.

For some apps, that means building the consumer experience first and handling the provider side manually until the volume justifies its own interface. For others, it means building the provider tools first because that's where the revenue comes from and the consumer side can start simple. The admin dashboard almost always waits. You can manage the back end through direct database access or simple tools until the platform is big enough to need a proper dashboard.

I know that sounds like cutting corners. It's not. It's sequencing. Build one thing well instead of three things poorly. The user type you start with gets your full attention, your full design effort, and your full budget. The others come when you've proven the model works.

How to spot this early

If your app description includes any of these phrases, you're probably looking at multiple apps: "connects buyers and sellers," "has an admin panel," "different users see different things," "there's a management side," or "some users create content and others consume it." Each of those implies a separate user type with separate needs.

Map it out early. Before you talk to a designer or a developer, list every type of person who'll use your app and what they need to do. If you've got more than two distinct user types, you need to know that before you set a budget. Not after.

The earlier you understand the real scope, the better the decisions you'll make about where to invest first. There's nothing wrong with a multi-user-type app. Some of the most successful products in the world are exactly that. But they didn't launch all three sides on day one. Neither should you.

Sources
Strategies for Two-Sided Markets (Harvard Business Review) - Multi-sided platforms require separate strategies for each user type.
Personas vs. Jobs-to-Be-Done (Nielsen Norman Group) - Understanding distinct user needs drives better design outcomes.

Related blog posts:

One app, three users: permission layers →

The real cost of designing and building an app →

What is an MVP? →