When One MVP Is Really Four Systems: A Better Way to Plan Multi-Role Apps

Teams often say they are building one app. A lot of the time, that is not true.

I saw this while reviewing a telemedicine MVP. At first, the plan sounded simple enough: video visits, messaging, scheduling, and basic records.

Then the version-one list kept growing:

• Patient app
• provider dashboard
• Admin panel
• Messaging
• Video
• Billing
• EHR connection
• Device support later

At that point, this was no longer one app. It was several systems being planned as one MVP.

• A patient-facing product
• A provider-facing product
• An admin product
• A set of outside-service connections

When a team treats all of that like one first release, things get messy before development even starts.

The Moment It Stopped Being One App

The problem was not the number of screens. The problem was the number of users, roles, and data rules hiding behind those screens.

A patient needed intake, booking, reminders, and follow-up. A provider needed schedules, patient context, notes, and quick actions during the day. An admin needed visibility, support tools, and role controls. The outside-services side added video vendors, messaging vendors, EHR work, and, later, device data.

That is not one product. That is a group of different systems with different jobs. Once that became obvious, the planning changed.

Split the Product by User First

Before estimating anything, it helps to split the product by who it is for. For this telemedicine project, the first useful split looked like this:

1. Patient Side

This part handled:

• Intake
• Booking
• Reminders
• Follow-up messaging
• Joining a visit

The patient's side had to stay simple. It also had to be clear about what the patient could and could not see.

2. Provider Side

This part handled:

• Schedule view
• Patient details
• Visit notes
• Quick responses
• Role-based access

This was not just a different set of screens. It had different speed needs, different daily habits, and different data access rules.

3. Admin Side

This part handled:

• Role setup
• Support actions
• Visibility into operations
• Reporting
• Non-clinical controls

Admin work often looks small during planning. In real projects, it adds a lot of rules and a lot of testing.

4. Outside-Service Work

This part handled:

• Video vendor setup
• Messaging vendor setup
• EHR-related work
• Future device data
• Logging and audit-related movement of data

This is where many teams get surprised. Video, messaging, and EHR are not tiny add-ons. Each one brings its own work.

Start With Access Rules Before the Feature List

In multi-role products, one of the quickest ways to find hidden work is to define access rules early.

Before locking the feature list, ask:

• Who can create this data
• Who can read it
• Who can change it
• Who can delete it
• Who can export it

For the telemedicine project, this made a big difference. A few features looked simple in the scope doc. Once the team asked who could view or change the related data, the work got much larger.

A basic example: Admins can help fix booking problems.

That sounds harmless.

But then the real questions start:

• Can admins see messages?
• Can they see visit notes?
• Can they see call history?
• Can they open uploaded files?

That one sentence can change a big part of the system. Access rules often show hidden work much faster than a feature list does.

Treat Outside Services as Separate Work

Another mistake teams make is treating outside services like small items on a checklist.

On paper, it can look like this:

• Video
• Messaging
• EHR later

In practice, each one adds its own work:

• Vendor setup
• Request and response formats
• Error handling
• Retry rules
• Logging
• Replacement cost if the vendor needs to change later

That is why these items should be planned separately.

For the telemedicine case, once video, messaging, and EHR work were split out from the main product list, the first release became easier to define. Some items that seemed close to launch were clearly not ready for version one.

Ship One Complete Path First

Once the team stopped calling everything an MVP, the first release got smaller.

The version-one path that stayed in looked like this:

• Patient intake
• Appointment booking
• Secure video through the chosen vendor
• Follow-up messaging
• Basic provider access controls

That was enough to test whether the product solved a real problem for a clinic.

What moved out of the first release:

• Deeper EHR work
• More reporting
• Detailed billing flows
• Device support
• Broader admin tooling

Those things were not bad ideas. They just did not belong in the first build.

4 Simple Documents to Create Before Sprint Planning

When a team starts to suspect that one MVP is several systems, four short documents can help a lot.

1. User-to-System Map

List each part of the product and the main user for it.

2. Permission Matrix

Write down who can create, view, change, delete, and export each type of data.

3. Outside-Service List

Separate core product work from vendor work and data that moves in or out of the system.

4. First-Release Path

Write the one end-to-end path that version one has to get right.

These are short documents, but they make planning much better.

Why This Matters Outside Healthcare, Too

This lesson is not only for telemedicine. It applies to any multi-role product where the team is building for more than one type of user.

That includes:

• Customer apps with admin panels
• SaaS products with back-office tools
• Platforms with provider and client sides
• Products that depend on outside vendors from day one

The moment a team has different users with different goals, the work stops being “just one app.”

Final Point

A lot of MVPs get too big because teams keep calling them one product long after that stops being true. The fix is not always better estimates.

Sometimes the fix is much simpler:

• Split the product by user.
• Write down the access rules.
• Separate outside-service work.
• Ship one complete path first.

That makes the first release easier to plan, easier to build, and easier to test.