FitIL has three user types. The trainee following a plan, the trainer writing it, and the gym owner counting both. They share a domain and almost nothing else. The trainee wants today's workout and nothing more. The trainer wants to author and adjust across many people. The owner wants to know whether any of it is working as a business.
Each of those is a good product on its own, and that is the trap. The obvious moves are to build three products, or to build one and bolt the other two on as modes. Both produce something that serves nobody particularly well.
Where multi-sided products actually break
- Navigation written for the union of all three. Every user pays for the other two by walking past their features on the way to their own.
- One primary action per screen stops being possible, because three roles want different primary actions from the same object. A plan is a thing to follow, a thing to edit, and a row in a report.
- The least frequent user drives the information architecture, because their needs are the most structural. The daily user then gets a filing system instead of a workout.
- Permissions leak into the interface. Once a screen has to check who is looking, it starts showing disabled controls, and a disabled control is a worse answer than an absent one.
The one who opens it every day should never see the machinery built for the one who opens it every quarter.
Frequency decides the surface
The rule that kept this coherent is that how often someone opens the app determines what they get when they do.
- The trainee opens it daily, so their surface is the default and it is nearly empty by design: the plan, today, done. Speed is the feature. Anything that is not this session is in the way.
- The trainer opens it weekly to author, so their surface is a workspace and it is allowed to be dense. Density is correct here, because they arrived to do a job that takes concentration.
- The owner opens it monthly to check numbers, so their surface is a report. It does not need to be fast. It needs to be complete, and it needs to be trustworthy enough to make a decision from.
Stated that way it sounds obvious. It is not what teams do. What teams do is give every role the same shell with different contents, because that is what a component library encourages, and the result is a daily user navigating an interface built for a monthly one.
Share the model, never the interface
Underneath, there is one data model and it does not fork. Same plan object, same exercise library, same session record. Three completely different readings of the same rows. That part must be shared, because the moment the trainer's idea of a plan and the trainee's idea of a plan are two structures, you are running a synchronisation problem instead of a product.
What you must not share is the interface. Reusing components across roles with different frequencies is how you end up with a dashboard someone is supposed to consult between sets. The components can share a design language. They should not share layouts.
The acquisition problem this creates
There is a second reason coherence matters here, which is that the growth engine was built before the audience existed. When you are acquiring three sides at once, an interface that half-serves each of them makes every channel harder simultaneously, and the sides are not independent: trainees without trainers have nothing to follow, trainers without trainees have nobody to write for, and an owner with neither has nothing to count.
So the weakest side caps the other two, and a muddled interface guarantees you have a weakest side. Coherence in a multi-sided product is not an aesthetic preference. It is what stops one side from limiting the whole thing.
How to tell if you have got it wrong
The cheap diagnostic is to watch the most frequent user do their most common task and count what they pass on the way. If the person opening the app to do one thing, every day, has to think about which part of the product they are in, the architecture is serving somebody who is not there.
The other test is to ask what each role would remove. If all three would remove roughly the same things, those things are decoration and should go. If each would remove what the others need, you have a real multi-sided product and the job is separation, not simplification.