
How to Make an App Like BlueJeans

How to Make an App Like BlueJeans
Video conferencing stopped being a "nice to have" years ago. It's now the backbone of distributed work, telehealth consultations, virtual classrooms, and client meetings that used to require a plane ticket. BlueJeans — originally built as a cloud-first, interoperability-focused meeting platform — carved out its niche by making it easy for anyone to join a call from any device, browser, or room system without wrestling with plugins.
If you're planning to build something similar, this guide walks through the features, architecture, tech stack, timeline, and cost considerations involved in creating a video conferencing app like BlueJeans.
Why Build a Video Conferencing App in the First Place?
The market is crowded, but it's far from closed. Zoom, Teams, and Meet dominate the generalist space, which is exactly why specialised and vertical-focused platforms keep finding room to grow.
Opportunities still exist in:
- Vertical-specific conferencing — HIPAA-compliant telehealth, court-admissible legal depositions, proctored exams for edtech
- Region-specific platforms — data residency requirements in the EU, India, or the Middle East
- Embedded video — video as a feature inside an existing CRM, LMS, or field-service product
- Enterprise interoperability — connecting legacy SIP/H.323 room hardware to modern cloud meetings, which was BlueJeans' original differentiator
- Event and webinar platforms — large-scale one-to-many broadcasting with interactive layers
The winning strategy is rarely "a better Zoom." It's "the only video platform that does X properly for Y industry."
What Makes BlueJeans, BlueJeans?
Before you build, understand what you're benchmarking against. BlueJeans' core value propositions were:
- Browser-first joining — no mandatory downloads via WebRTC
- Interoperability — bridging Skype for Business, SIP, H.323, and room systems into one meeting
- Dolby Voice audio — spatial audio and noise reduction as a headline differentiator
- Smart Meetings — highlights, action items, and searchable recordings
- Enterprise controls — SSO, analytics dashboards, and admin governance
Pick which of these matter for your audience. Trying to match all five on day one is how MVPs die.
Core Feature Set
Must-Have Features (MVP)
User accounts and authentication Email/password, social sign-in, and SSO via SAML or OAuth for enterprise clients. Role hierarchy: account owner, admin, host, participant, guest.
Meeting scheduling One-click instant meetings, scheduled meetings with recurring options, calendar integration with Google Calendar and Outlook, and unique join links with optional passcodes.
Real-time audio and video Multi-party video with adaptive bitrate, active speaker detection, gallery and speaker view layouts, and device selection for camera, mic, and speaker.
Screen sharing Full desktop, single application window, or browser tab sharing — with annotation as a fast-follow.
In-meeting chat Public and private messaging, file sharing, emoji reactions, and persistence after the meeting ends.
Host controls Mute all, remove participants, lock the meeting, waiting room/lobby, and co-host delegation.
Recording Cloud recording with transcoding, plus local recording options. Store recordings with access controls.
Differentiating Features (Phase 2+)
- Live transcription and captions using speech-to-text APIs
- AI meeting summaries — action items, decisions, and topic highlights
- Breakout rooms for workshops and classrooms
- Virtual backgrounds and noise suppression via ML-based segmentation
- Whiteboard and collaborative canvas
- Polls, Q&A, and hand raising
- Webinar mode with attendee/panelist separation and streaming to YouTube or LinkedIn
- Analytics dashboard — meeting quality scores, usage by department, network diagnostics
- Room system interoperability via SIP/H.323 gateways
- Meeting highlights — timestamped clips users can share without sending a 90-minute file
Technical Architecture
This is where video apps get genuinely hard. The UI is straightforward; the media pipeline is not.
WebRTC Is the Foundation
WebRTC handles peer-to-peer media capture, encoding, and transport in the browser and on mobile. It gives you the codecs (VP8, VP9, H.264, AV1, Opus), encryption (DTLS-SRTP), and NAT traversal primitives out of the box.
But raw WebRTC peer-to-peer only scales to about 3–4 participants before every client is uploading four separate streams and melting laptops. For anything larger, you need a media server.
Choosing Your Media Topology
Mesh (P2P) Every participant connects to every other participant. Zero server media cost, lowest latency, but bandwidth scales quadratically. Fine for 1:1 and small calls only.
SFU (Selective Forwarding Unit) Each client uploads one stream to the server; the server forwards relevant streams to everyone else. This is the industry standard for group video. Combined with simulcast (clients send multiple resolution layers) or SVC (scalable video coding), the SFU can send each participant the right quality for their bandwidth.
MCU (Multipoint Control Unit) The server decodes, composites, and re-encodes everything into a single stream. CPU-expensive but essential for interoperability with legacy room hardware and for streaming out to RTMP endpoints.
Most production platforms run a hybrid: SFU for the main meeting, MCU only for recording composition, live streaming, and SIP/H.323 bridging.
Open-source media servers worth evaluating: mediasoup, Janus, Jitsi Videobridge, LiveKit, and Pion for Go-based custom builds.
Signalling Layer
Before media flows, clients need to exchange session descriptions and ICE candidates. This runs over WebSockets and handles room state, participant presence, mute status, and control messages. Keep it stateless where you can and back it with Redis pub/sub for horizontal scaling.
TURN and STUN
Roughly 10–20% of connections will fail direct peer connections due to restrictive firewalls and symmetric NAT. You need STUN servers for address discovery and TURN servers to relay media when direct paths fail. Coturn is the standard open-source option. Budget for TURN bandwidth — it's a real line item.
Global Edge Distribution
Latency kills meeting quality. Deploy media servers across multiple regions and route users to the nearest edge. Cascading SFUs — where regional servers interconnect — let a participant in Singapore and one in London each connect to a local node rather than both hairpinning across the planet.
Recommended Tech Stack
| Layer | Options |
|---|---|
| Media | WebRTC, mediasoup / LiveKit / Janus |
| Signalling | Node.js + Socket.IO, or Go + Gorilla WebSocket |
| Backend API | Node.js (NestJS), Go, or Python (FastAPI) |
| Web frontend | React or Next.js with TypeScript |
| Mobile | React Native or Flutter for speed; Swift + Kotlin for maximum media control |
| Desktop | Electron or Tauri |
| Database | PostgreSQL for relational data, Redis for session state |
| Storage | S3 or equivalent object storage for recordings |
| Transcoding | FFmpeg, AWS Elemental MediaConvert |
| AI layer | Whisper for transcription, LLM APIs for summarisation |
| Infrastructure | Kubernetes, Terraform, multi-region cloud |
| Monitoring | Prometheus, Grafana, plus WebRTC-specific QoS metrics |
Build vs. Buy
You don't have to build the media layer yourself. CPaaS providers like Agora, Twilio Video, Daily, 100ms, and LiveKit Cloud give you SDKs and managed infrastructure.
Buy when: you're validating a product, video is a feature not the product, or you need to ship in under three months.
Build when: video is the product, per-minute pricing will crush your margins at scale, you need deep custom media processing, or you have strict data residency and compliance requirements.
A common path is to launch on a CPaaS, prove demand, then migrate the media layer in-house once unit economics justify it.
Security and Compliance
Video platforms handle some of the most sensitive data a company produces. Treat security as a launch requirement, not a roadmap item.
- Encryption in transit — DTLS-SRTP is baked into WebRTC; enforce TLS 1.3 everywhere else
- End-to-end encryption — optional E2EE mode using insertable streams for sensitive meetings (note: this disables server-side recording and transcription)
- Meeting access controls — passcodes, waiting rooms, domain-restricted joining, and expiring links
- Encryption at rest for recordings and transcripts
- Compliance — HIPAA for healthcare, FERPA for education, GDPR for the EU, SOC 2 Type II for enterprise procurement
- Data residency — region-pinned storage and processing for regulated markets
- Audit logging for every admin action and recording access
Also plan for abuse: rate limiting on meeting creation, detection of "conference bombing" patterns, and reporting tools.
UX Principles That Actually Matter
Video UX succeeds by getting out of the way.
Joining must be frictionless. A link should open a browser and put someone in the meeting in under ten seconds. Every step you add — download this, create an account, allow these permissions — loses participants.
Pre-join device check. Let people confirm their camera, mic, and speaker work before anyone sees them. This single screen prevents most "can you hear me?" openings.
Graceful degradation. When bandwidth drops, reduce video resolution before touching audio. Audio continuity matters far more than video sharpness. Show a clear, non-alarming network indicator.
Predictable controls. Mute, camera, share, leave. Keep them in the same place, always visible, with keyboard shortcuts.
Accessibility. Live captions, screen reader support, keyboard-only navigation, and sufficient contrast. In education and government contexts this is a procurement requirement, not a bonus.
Monetisation Models
- Freemium — free tier with participant caps and 40-minute limits, paid tiers for longer meetings and larger rooms
- Per-host subscription — the standard B2B SaaS model, priced per licensed host per month
- Enterprise contracts — annual agreements with SSO, admin controls, SLAs, and dedicated support
- Usage-based — per-minute or per-participant-minute billing, common for embedded/API products
- Add-ons — extra cloud recording storage, webinar capacity, dial-in telephony, AI features
- White-label licensing — sell the platform for other companies to brand as their own
Development Timeline
Discovery and design (3–5 weeks) Market research, feature prioritisation, technical architecture decisions, wireframes, and UI design system.
MVP build (12–20 weeks) Auth, scheduling, core 1:1 and small-group calling, screen share, chat, basic host controls, web client first.
Scale and harden (8–12 weeks) SFU optimisation, simulcast, TURN infrastructure, multi-region deployment, recording pipeline, load testing.
Mobile and desktop clients (8–14 weeks) Native or cross-platform apps with background audio, CallKit/ConnectionService integration, and push notifications.
Advanced features (ongoing) Transcription, AI summaries, breakout rooms, webinars, analytics, integrations.
Realistically, a credible production-grade platform takes 7 to 12 months to reach a confident v1.
Cost Considerations
Development cost depends heavily on scope and team location, but the broad brackets look like this:
- CPaaS-based MVP, web only: $40,000 – $80,000
- Cross-platform MVP with mobile apps: $80,000 – $160,000
- Custom media infrastructure, multi-region, enterprise features: $200,000 – $500,000+
Don't forget ongoing operational costs, which surprise most first-time founders:
- Media server compute (the largest line item at scale)
- TURN relay bandwidth
- Recording storage and egress
- Transcoding CPU/GPU time
- Speech-to-text and LLM API usage
- Compliance audits and penetration testing
- 24/7 monitoring and on-call
Common Mistakes to Avoid
Testing only on fast Wi-Fi. Your users will be on hotel networks, mobile data, and overloaded home connections. Test with simulated packet loss, jitter, and bandwidth caps from day one.
Underestimating mobile. Battery drain, thermal throttling, background handling, and interruptions from incoming phone calls all need explicit engineering attention.
Ignoring observability. You cannot fix quality problems you can't measure. Instrument WebRTC stats — round-trip time, jitter, packet loss, freeze duration, bitrate — per participant, per session, from launch.
Building every feature. Breakout rooms, whiteboards, and AI summaries are seductive. Nobody will use them if your core call drops.
Treating scale as a later problem. The architecture decisions you make at 10 users determine whether 10,000 users is a config change or a rewrite.
Final Thoughts
Building an app like BlueJeans is fundamentally an infrastructure challenge dressed up as a product challenge. The interface is the easy part — reliable, low-latency, globally distributed real-time media is where the real engineering lives.
The good news is that the ecosystem has matured enormously. Open-source SFUs, mature CPaaS platforms, and commodity AI APIs mean a small, focused team can now ship something genuinely competitive. The teams that win are the ones who pick a specific audience, nail reliability for that audience, and resist the urge to chase feature parity with platforms that have thousand-person engineering departments.
Start narrow. Make the call never drop. Everything else follows.
Have a project in mind? Contact Sodio Technologies to discuss your requirements and explore the right technology solution for your business.
/// Work with us
Talk to the engineers who'd build it
You'll get a technical scope, timeline and cost estimate from the people doing the work, not an account manager. In-house team, no subcontracting, since 2016.
