Skip to main content

Build Style Guide

Use this page when your main question is not "can MediaSFU do it?" but "which integration style should we start with?"

The blunt recommendation model​

If your product looks like...Start hereWhy
A meeting room with light brandingQuickstart + UI overridesFastest path, least moving parts.
A branded room with a custom shellCustom component replacementKeep MediaSFU workflow, replace larger surfaces.
A custom operator console, live host workspace, or non-room UIHeadless modeKeep runtime helpers, own the whole presentation layer.
A wrapper, framework adapter, or deeply custom runtimemediasfu-sharedLowest-level control across producers, consumers, transports, and sockets.

Decision ladder​

Level 1: Prebuilt UI first​

Choose this when:

  • you need the fastest time to first working room
  • the default room model already fits most of the product
  • your team has not yet validated join, permissions, and device flows

Stay here if the main work is branding, copy, or layout polish.

Level 2: UI overrides​

Choose this when:

  • the default room workflow is good
  • specific cards, controls, modals, or prejoin surfaces need product polish
  • you want to change presentation without taking ownership of the full shell

This is the best first customization layer for WhatsApp-style or branded-room builds.

Level 3: Custom component replacement​

Choose this when:

  • you need to replace compound surfaces or navigation flows
  • the product has a strong existing shell around the room logic
  • you still want MediaSFU to manage sockets, transports, and state coordination

This is the best fit for host dashboards, branded workspaces, and CRM-style shells.

Level 4: Headless or shared-core​

Choose this when:

  • the product no longer resembles a meeting room
  • you want your own shell from the first visible screen onward
  • your team needs direct access to helpers such as clickVideo, clickAudio, or runtime transport utilities

Move from a UI SDK in headless mode to mediasfu-shared only when the UI SDK stops being useful.

  1. Prove the secure join flow with Secure Backend Proxy.
  2. Validate the prebuilt room before changing major UI surfaces.
  3. Use UI overrides before customComponent.
  4. Use custom component replacement before going fully headless.
  5. Use mediasfu-shared only when you need lower-level runtime control than the UI SDKs expose cleanly.

Migration signals​

Move up the ladder when one of these becomes true:

  • You are replacing multiple modal families, navigation, and room shell at once.
  • Your UI no longer resembles a room or webinar surface.
  • You need your own routing and workspace composition around MediaSFU state.
  • Your product team wants to reuse MediaSFU runtime but not its default presentation model.

Common mistakes​

  • Starting headless before validating the stock flow.
  • Replacing too many surfaces before device and permission handling works.
  • Using mediasfu-shared too early when uiOverrides or customComponent would have been enough.
  • Treating secure backend setup as optional. It is not.

Best references by path​