The "two apps" pitch

When we started designing, the conventional move was two apps. Coaches Pro on the App Store, Teshape (consumer) on the App Store. Separate downloads, separate icons, clean separation of concerns. Every other coaching platform we looked at had done this.

We almost did it. The arguments for two apps were strong on paper: easier discovery, simpler permissions, smaller binaries. We talked to enough coaches to discover the arguments were wrong on use.

The single-binary architecture

The killer insight came from a coach who said: "I am also a trainee with my own coach. With two apps, I would have to log into one to coach and another to be coached. That is two passwords, two sets of notifications, two icons on my home screen."

Coaches who also have coaches are not an edge case. They are the median. Coaches who do not get their own coaching are the minority. The "two apps" model serves the minority and inconveniences the majority.

The role switcher UX

One login, one app, a portal toggle in the profile drawer. Switching roles takes one tap. The notification stack stays unified. The chat threads stay unified. A coach reviewing a trainee's check-in can swap to their own trainee view and see their own coach's reply without leaving the app.

The trade-off

The binary is roughly 18% larger than a trainee-only or coach-only version would be. The runtime memory profile is similar enough that we did not have to make compromises. The trade-off is small enough that no user has ever surfaced it as a complaint.

The UX win, on the other hand, surfaces in every user research session we run. The "I am both" use case keeps validating the architecture decision two years in.