The systems cut — one shell, two role surfaces.
Dual-role UX is easy to underestimate because it looks like a technical problem — permissions, contexts, session states. It is that, but the harder part is making the same application shell serve two genuinely different cognitive modes without forking into two apps. That's the systems throughline of Visianary: keep one product, let it be two things cleanly.
Dashboard architecture ↔ user types
The architecture has to let a single account hold two role surfaces — a crew profile built around credits and availability, a producer dashboard built around project management and crew coordination — and move between them without a separate login or a buried settings toggle. The "Switch to managing" pill is the user-facing seam; underneath it is mode/context state that swaps the task surface while keeping identity continuous. The open architectural question is how much the two contexts share (your own profile, your connections) versus keep fully separate (the primary task surfaces). That's still an open architectural question on a live build, so I'm describing the intent — one shell, two role surfaces, identity continuous across the switch — rather than claiming a final implementation I'd have to walk back.
Design system — data-powered components
The component layer is where "one product, two modes" is enforced: data-powered components that bind to different data per surface but share one branding-first vocabulary, so the crew and producer views stay recognizably the same product. The concrete token/data-binding specifics I'm leaving for when the live build is far enough along to show them — the principle, not a spec I can't yet back.