Deep dive
Build for one kind of community
General community chat is crowded. What works is a focused audience with needs that general tools miss: a game studio that wants player communities tied to accounts and in-game events, a creator who wants paid membership tiers, a course that wants cohorts and office hours, or a company that wants a customer community with support integration.
That focus also simplifies the MVP. A creator community needs memberships early; a gaming community needs voice quality and bots; a learning community needs scheduled events and threads. Our MVP development process picks the few features that make the chosen community stay.
Plan the first hundred members as carefully as the first hundred lines of code. Invite active people who already talk elsewhere, give them roles and a say in the channel structure, and schedule regular events so there is always a reason to drop in. Communities that feel busy in their first weeks keep growing; quiet ones rarely recover, however good the software is.
How voice rooms work
When a member joins a voice channel, their app opens a WebRTC connection to a selective forwarding unit, an SFU. Each speaker sends one audio stream; the SFU forwards it to everyone else in the room without mixing, so latency stays low and the server does little processing. Opus audio handles poor networks gracefully, and an on-device noise suppression model removes keyboards and fans.
LiveKit and mediasoup are mature open-source SFUs; LiveKit also offers a managed cloud. Place media servers in the regions where your users are, use TURN relays for restrictive networks and measure packet loss, jitter and round-trip time per region. Video and screen sharing reuse the same infrastructure with simulcast so each viewer gets a quality that suits their connection.
- Route each room to the media server nearest most of its members.
- Use voice activity detection so silent members send almost nothing.
- Show connection quality to users so they know when the problem is on their side.
- Fall back to audio-only automatically when bandwidth drops, rather than freezing video for everyone.
Permissions, roles and the gateway
Permissions are computed from server defaults, role grants and channel overrides, in a fixed order. Put that logic in one engine on the server and expose computed permissions to clients, so every feature, from message sending to voice and bots, uses the same rules. Cache results and invalidate them when roles change.
The real-time gateway keeps a WebSocket open per client and sends only events for servers and channels the client is viewing. Large servers send member lists lazily and presence updates in batches. Messages are stored per channel in a wide-column store, which keeps recent history fast to load.
Safety, moderation and young users
Community admins need strong tools: timeouts, bans, slow mode, automod rules, verification levels for new members and audit logs. The platform adds a layer underneath: hash matching for known illegal images, classifiers for harassment and spam, grooming signals and a trust and safety team that handles reports and legal requests.
Regulation focuses on children. The UK Online Safety Act's child safety duties have applied since July 2025, the amended US COPPA rule covers under-13s, and other countries are adding age rules for social services. Plan age checks proportionate to risk, safer defaults for teens such as filtered direct messages, and reporting that works in a few taps.
Running costs
Voice and video are the largest variable costs: SFU compute, TURN bandwidth and regional servers grow with concurrent speakers rather than with users. Message storage, attachments and CDN delivery, search clusters and moderation APIs follow. Model cost per concurrent voice user before you set limits for free servers.
Maintenance is roughly 15-20% of the build cost per year, plus infrastructure. Our DevOps consulting team usually sets up regional capacity planning and alerting for voice before launch.