Huddle Meet: project facts
- Project
- Huddle Meet
- Period
- 2024
- Role
- Frontend Systems Engineer
- Summary
- Realtime WebRTC communication platform
- Description
- A realtime video meeting platform that has run billions of minutes. I worked on managing how people join and interact in meetings, building media toggles, host permission controls, and interactive features like emoji reactions and soundboards. I also helped with a major redesign to make the app feel like a premium tool rather than a quick hackathon project.
- Domains
- Realtime Systems, WebRTC, Participant Coordination, Permissions
- Technologies
- Next.js, React, WebRTC, Socket.io, TypeScript, React Query, Web3
- Ownership
- The layout redesign and mobile responsive views
- Ownership
- Realtime meeting controls (mic, camera, screen share triggers)
- Ownership
- Meeting settings interface for camera and mic testing
- Ownership
- Realtime chat, emoji reactions, and soundboard features
- Ownership
- Granular roles system (host, co-host, speaker, guest)
- Ownership
- PostHog analytics integration for feature usage tracking
- Learning
- People rarely notice good meeting UX. They only notice when something feels slow or when muting their mic takes more than one click.
- Professional signal
- I care a lot about making complicated realtime products feel smooth and obvious to use.
a realtime video meeting platform that has run billions of minutes. i worked on managing how people join and interact in meetings, building media toggles, host permission controls, and interactive features like emoji reactions and soundboards. i also helped with a major redesign to make the app feel like a premium tool rather than a quick hackathon project.
meetings should feel simple even when a lot is happening behind the scenes.
i started by finding annoying parts of the app and cleaning them up. then I rebuilt slow pieces, simplified controls, improved loading behavior, and made interactions feel faster.
we successfully shipped the new layout and performance fixes, helping support billions of meeting minutes. i became one of the main frontend contributors, working closely with our users to get feedback, and continuously adjusting our flows based on what they actually struggled with.
What I actually owned
- ·the layout redesign and mobile responsive views
- ·realtime meeting controls (mic, camera, screen share triggers)
- ·meeting settings interface for camera and mic testing
- ·realtime chat, emoji reactions, and soundboard features
- ·granular roles system (host, co-host, speaker, guest)
- ·postHog analytics integration for feature usage tracking
What became difficult
- ·things became difficult quickly.
- ·media permissions behave differently everywhere
- ·mobile browsers break things
- ·role syncing had to feel instant
- ·users expect zero delay
What I learned
people rarely notice good meeting UX. they only notice when something feels slow or when muting their mic takes more than one click.
What surprised me
i thought WebRTC would be the difficult part. browser behavior ended up causing more pain.
Before → After
| Before | After |
|---|---|
| slower page loads | cleaner UX |
| confusing controls | faster loads |
| weaker mobile experience | smoother interaction |
Small opinion
people never notice good meeting software. they only notice bad meeting software.
What I would improve now
i would rewrite our media state logic. it grew organically and ended up with too many nested hooks. a simpler, centralized state machine would be much cleaner. i would also build a more solid automated test suite for browser-level media devices since manual testing takes forever.
Random things I remember
- ·i spent two full days trying to figure out why Safari users couldnt hear soundboard effects, only to find out Safari blocks audio if the user hasnt clicked the page first.
- ·testing meetings by opening 20 browser tabs at once and listening to my own voice echo until my ears hurt.
i care a lot about making complicated realtime products feel smooth and obvious to use.