This project is a strong example of practical engineering judgment in a real-time product. It shows how I handled product complexity, challenged an approach with evidence instead of conflict, and used a working demo to guide the team toward a simpler and more scalable solution.

The Guest Box feature began to grow overly complex because leadership wanted too many related capabilities packed into a single version. At the same time, the Android lead proposed using a media-channel relay approach to turn a viewer into a co-host. That approach was not a good long-term fit because it would break down once multiple co-hosts needed to stream at the same time. It also added unnecessary complexity for a feature that needed to be reliable and easy to extend.

The hardest part was not only the technical implementation, but also aligning the team around a simpler solution without creating unnecessary conflict. I had already validated that using AgoraRTC's switch-role approach allowed a viewer to become a co-host cleanly and was much more suitable for multiple co-hosts. Meanwhile, the Android side had spent significant time pursuing a more complicated relay-based direction and was falling behind. I needed to prove a better path in a professional way that would keep the project moving and preserve team alignment.

• Implemented the iOS Guest Box flow that allowed viewers to request co-host access and become live co-hosts after acceptance.
• Validated that a switch-role approach in AgoraRTC was simpler and more scalable than the media-channel relay direction being explored elsewhere.
• Built a working demo to show the feature behavior clearly instead of arguing about architecture in the abstract.
• Helped move the team toward a solution that would support multiple co-hosts more cleanly.

• Focused on the actual user transition: viewer requests co-host access, streamer accepts, viewer switches role and joins as an active broadcaster.
• Used AgoraRTC's switch-role method because it matched the product need more directly and avoided the complexity of relaying media as if the user were becoming a separate primary streamer.
• Kept the implementation as simple as possible so the feature could remain understandable, stable, and easier to extend later.
• Created a concrete demo to validate the flow end to end and make the technical tradeoffs visible to the team.

• Worked with product and design while feature scope was becoming overly ambitious for a single release.
• Shared a working iOS demo with management to demonstrate that the simpler approach already worked in practice.
• Handled the disagreement with the Android lead professionally by focusing on evidence and delivery rather than debate.
• Helped the team align on a common implementation direction once the demo made the tradeoffs clear.

• Chose a simpler, role-based solution over a more complicated relay-based model because it better supported multiple co-hosts.
• Used a working prototype to guide technical alignment instead of turning the disagreement into a prolonged architectural argument.
• Prioritized a solution that could ship reliably and scale with the feature's likely future needs.
• Avoided unnecessary conflict by letting implementation evidence speak for itself and giving others room to accept the better path without losing face.

• Delivered a working Guest Box implementation on iOS while the Android side was still blocked on approach.
• Helped the team converge on a simpler and more scalable co-hosting solution.
• Reduced delivery risk by avoiding a more complicated architecture that would have struggled with multiple simultaneous co-hosts.
• Kept the feature moving forward during a period where scope complexity and technical disagreement could easily have delayed release further.

• A working demo is often the safest and most effective way to resolve technical disagreement.
• In cross-team situations, evidence usually creates better alignment than direct argument.
• Simpler solutions are especially valuable in real-time systems, where added complexity multiplies quickly.
• Technical leadership sometimes means helping the team change direction without turning it into a personal conflict.

• I would push earlier for tighter scope control so core live-streaming features are not overloaded into a single release.
• I would document the scalability limits of alternative approaches sooner so the team can evaluate them more objectively.
• I would add stronger technical notes around co-host state transitions and multi-host behavior to make future extensions easier.