Coffee Tea

Coffee Tea

Overview

Coffee Tea is live interview coaching with human mentors, not an AI. Candidates book real video sessions, practice under realistic pressure, and get structured feedback after each one. WebRTC carries the media with STUN/TURN fallback and automatic reconnection; Firestore handles signaling and availability; Stripe handles booking and payout. The difference from Preplify: a person on the other side.

The product addresses a specific gap in interview preparation: static question banks and recorded content can't replicate the pressure, pacing, and interpersonal dynamics of a real interview. Coffee Tea creates a live coaching environment where candidates practice with experienced mentors who provide real-time feedback, structured evaluations, and longitudinal progress tracking.

A key design consideration was the psychology of the user experience. Interview preparation is inherently anxiety-inducing, and the platform's visual design and motion system are intentionally crafted to create an encouraging, professional atmosphere rather than amplifying stress.

Business Context: Real-World Interview Simulation

Most interview preparation tools focus on content - question databases, answer frameworks, tips and tricks. But the actual challenge of interviewing is the live interaction: managing nerves, thinking on your feet, reading the interviewer's reactions, and maintaining composure under pressure. These skills can only be developed through practice with another person.

The core problem: Candidates can memorize answers to common questions, but they can't practice the conversational dynamics of a live interview without a live partner. Finding practice partners informally is unreliable - scheduling conflicts, inconsistent feedback quality, and no accountability.

Stakeholder perspective:

• ›Candidates need reliable, low-friction access to experienced interviewers for realistic practice sessions. They want structured feedback they can act on, progress tracking across sessions, and a platform that feels encouraging rather than intimidating.
• ›Mentors need a platform that handles scheduling, payments, and session logistics so they can focus on coaching. They need tools to provide structured feedback efficiently and manage their availability and client load.
• ›The business needs a platform where the transaction (session booking and payment) feels like a natural part of the experience, not a friction point that interrupts the user's preparation momentum.

Constraints that shaped the architecture:

• ›WebRTC peer-to-peer connections require a signaling mechanism for initial connection setup. Firebase's real-time database provides this naturally through Firestore document listeners, eliminating the need for a custom WebSocket signaling server.
• ›Video session quality is the product - if the video lags, stutters, or drops, the entire value proposition fails. Connection reliability had to be a first-class architectural concern, not an afterthought.
• ›Payment flows must feel integrated into the booking experience, not like a separate "checkout" process that breaks the user's flow from discovering a mentor to starting a session.
• ›The platform must work well on mobile devices, as candidates often practice from home on phones or tablets rather than desktop setups.

What I Built

1. WebRTC Video Session System

• ›Peer-to-Peer Connection Management: Built the WebRTC integration handling the full connection lifecycle - creating peer connections, exchanging Session Description Protocol (SDP) offers and answers through Firestore documents, gathering and exchanging ICE candidates for NAT traversal, and establishing direct media streams between candidate and mentor browsers.
• ›Signaling via Firestore: Used Firestore real-time listeners as the signaling channel for WebRTC. When a candidate initiates a session, a Firestore document is created with the SDP offer. The mentor's client listens for this document, responds with an SDP answer, and both clients exchange ICE candidates through subcollections. This leverages Firebase's existing real-time infrastructure instead of building a separate signaling server.
• ›STUN/TURN Configuration: Configured STUN servers for NAT traversal (discovering public IP addresses) and TURN relay servers as fallback for connections that can't establish direct peer-to-peer paths (symmetric NATs, restrictive firewalls). The system automatically falls back to relay mode when direct connections fail, ensuring session reliability at the cost of slightly higher latency.
• ›Connection Health Monitoring: Implemented real-time monitoring of WebRTC connection statistics (round-trip time, packet loss, available bandwidth) with visual quality indicators in the UI. When connection quality degrades beyond thresholds, the system attempts ICE restart to re-establish the optimal connection path, and the UI communicates the current state to users (e.g., "Reconnecting..." with a progress indicator rather than an abrupt disconnect).

2. Firebase-Powered Mentor Matching & Availability

• ›Real-Time Availability State: Built mentor availability using Firestore documents that update in real-time. When a mentor marks themselves available, their profile appears in candidate search results within seconds (Firestore's real-time listener propagation). When they begin a session or go offline, their availability updates immediately for all browsing candidates.
• ›Mentor Discovery & Filtering: Built a browsable mentor directory with filtering by specialization (technical, behavioral, system design), industry experience, language, and availability window. Search results use Firestore compound queries and client-side sorting by relevance (match score based on candidate's target role and mentor's expertise).
• ›Session Coordination via Cloud Functions: Cloud Functions handle session lifecycle events - when a booking is confirmed, a function creates the session record, sends confirmation notifications to both parties, schedules reminder notifications (30 minutes before, 5 minutes before), and creates the Firestore signaling document that the WebRTC layer will use for connection setup.

3. Stripe Payment & Booking Integration

• ›Integrated Booking Flow: Designed the booking experience so that payment feels like a natural step in session scheduling, not a separate transaction. The flow is: select mentor → choose available time slot → review session details and pricing → confirm and pay → receive booking confirmation with session link. Each step uses Framer Motion transitions that maintain visual continuity.
• ›Stripe Elements Integration: Payment collection uses Stripe Elements for PCI-compliant card input, with payment intents created by a Cloud Function when the user enters the payment step. The Cloud Function calculates the session price (base rate + any specialty surcharges), creates the intent, and returns the client secret for client-side confirmation.
• ›Webhook-Based Confirmation: Stripe webhook events trigger Cloud Functions that finalize the booking - mark the session as paid, update the mentor's availability (remove the booked time slot), send confirmation emails to both parties, and create calendar entries. This ensures the booking is confirmed even if the candidate's browser disconnects after payment.
• ›Mentor Payout Tracking: Built backend logic in Cloud Functions to track mentor earnings per session, calculate platform fees, and maintain payout ledgers. Mentors can view their earnings and payout history in their dashboard.

4. Anxiety-Reducing UI & Motion Design

• ›Purposeful Animation System: Implemented a Framer Motion animation library where every animation serves a functional purpose - page transitions use smooth crossfades to reduce the jarring effect of navigation, loading states use gentle pulse animations instead of aggressive spinners, success states use celebratory but subtle motion, and session entry uses a "breathing" transition that gives candidates a moment to compose themselves before the video activates.
• ›Encouraging Visual Language: The design system uses warm color palettes, rounded corners, generous whitespace, and conversational microcopy ("You've got this!" rather than "Start session") intentionally chosen to create a coaching atmosphere rather than a testing environment.
• ›Session Interface Design: The video session interface is designed to minimize distractions - the mentor's video is prominent, the candidate's self-view is small and repositionable, and session controls (mute, end call, chat) are accessible but not visually dominant. A subtle timer shows elapsed time without creating time pressure anxiety.

5. Progress Tracking & Feedback System

• ›Structured Mentor Feedback: After each session, mentors complete a structured evaluation form covering key dimensions (communication clarity, technical depth, problem-solving approach, confidence, areas for improvement). The structured format ensures consistent, actionable feedback across different mentors.
• ›Candidate Progress Dashboard: Built a longitudinal progress view where candidates see their performance trends across sessions - radar charts showing improvement in different dimensions, session history with mentor notes, and personalized recommendations for focus areas.
• ›Session Recordings & Notes: Implemented optional session recording (with consent) stored in Firebase Storage, allowing candidates to review their performance. Mentors can add timestamped notes during the session that align with specific moments in the recording.

Architecture Highlights

WebRTC + Firebase: The Real-Time Stack

The architecture leverages Firebase as the "connective tissue" for real-time operations:

• ›Firestore serves as the WebRTC signaling channel (SDP exchange, ICE candidates), real-time availability state, and live session metadata.
• ›Cloud Functions handle all server-side logic that shouldn't run on the client - payment processing, notification scheduling, session lifecycle management, and security-sensitive operations.
• ›Firebase Authentication provides the identity layer for both candidates and mentors.

This architecture avoids the need for a traditional backend server for real-time operations. Firestore's real-time listeners handle the signaling and availability use cases that would typically require WebSocket servers, and Cloud Functions handle the event-driven server logic that would typically require an Express.js API.

Why Firebase over a custom backend: The real-time requirements (signaling, availability updates, session coordination) would require WebSocket infrastructure that needs to be highly available and low-latency. Firebase provides this out of the box with global distribution, automatic scaling, and managed infrastructure. Building equivalent real-time infrastructure from scratch would have been a significant engineering effort that diverts from the core product.

WebRTC Connection Resilience

Video session reliability is the product - a dropped call during a mock interview destroys the value of the session. The connection management layer addresses the common failure modes:

1. ›

   NAT Traversal: Most users are behind NATs that prevent direct peer-to-peer connections. STUN servers discover the user's public IP/port mapping, enabling direct connections through common NAT types. For symmetric NATs (common in corporate networks), TURN relay servers route media through an intermediary.

2. ›

   Connection Recovery: Network conditions change during sessions (WiFi → cellular handoff, temporary packet loss, bandwidth fluctuation). The system monitors WebRTC connection statistics and triggers ICE restart when metrics degrade, re-establishing the optimal connection path without dropping the session.

3. ›

   Graceful Degradation: When bandwidth drops, the system can reduce video resolution or switch to audio-only mode rather than dropping the connection entirely. The UI communicates the current quality level so users understand any visual degradation is intentional quality management, not a malfunction.

Stripe Integration via Cloud Functions

Payment processing follows a serverless pattern:

• ›Client → Cloud Function → Stripe: The client never communicates with Stripe directly for sensitive operations. Cloud Functions create payment intents, handle webhooks, and manage refunds.
• ›Idempotent Webhooks: Stripe may send the same webhook event multiple times. Cloud Functions use idempotency checks (storing processed event IDs in Firestore) to ensure booking confirmation logic runs exactly once per payment.
• ›Decoupled from UI: The payment confirmation flow is decoupled from the client - even if the user's browser crashes after clicking "Pay," the Stripe webhook triggers the Cloud Function that finalizes the booking. The user sees the confirmed booking when they return.

Motion Design as Functional UX

Framer Motion animations in Coffee Tea aren't decorative - they serve specific UX functions:

• ›Page transitions maintain spatial context, helping users understand where they are in the booking flow.
• ›Loading states use gentle animations that reduce perceived wait time and prevent the "is it broken?" anxiety that static loading indicators create.
• ›Session entry uses a deliberate "preparation" transition (a brief breathing animation with an encouraging message) that gives candidates a psychological moment to compose themselves before the video feed activates.
• ›Feedback reveals animate in progressively after a session ends, letting candidates absorb results at a comfortable pace rather than dumping all feedback at once.

Technical Deep Dive: WebRTC Session Management & Fallback Strategies

The most architecturally challenging aspect of Coffee Tea is the WebRTC session management layer - establishing, maintaining, and recovering peer-to-peer video connections in the unreliable conditions of real-world internet connectivity.

The Problem: WebRTC provides the browser APIs for peer-to-peer media streaming, but it doesn't provide the infrastructure or logic for session management. The developer is responsible for signaling (how peers discover each other and exchange connection metadata), NAT traversal configuration (how to establish connections through firewalls), connection monitoring (detecting degradation before it causes visible quality issues), and recovery (re-establishing connections when they fail).

The Architecture:

1. ›

   Signaling Layer (Firestore-based): When a session begins, the initiating peer (candidate) creates a Firestore document containing their SDP offer - a description of their media capabilities and connection preferences. The receiving peer (mentor) listens for this document, processes the offer, generates an SDP answer describing their own capabilities, and writes it back. Both peers then exchange ICE candidates (potential connection paths) through a Firestore subcollection, each listening for new candidates and adding them to their peer connection. Once a viable candidate pair is found, the media stream begins.

   The elegance of using Firestore for signaling is that it provides exactly the semantics needed: write a document, listen for changes, exchange data between two parties - all with built-in real-time synchronization and security rules.

2. ›

   ICE Candidate Strategy: The system configures multiple ICE server types in priority order:

   • ›Host candidates: Direct LAN connections (same network). Fastest but rarely applicable for internet sessions.
   • ›Server-reflexive candidates (STUN): Public IP/port mappings discovered through STUN servers. Works for most residential NATs.
   • ›Relay candidates (TURN): Media routed through a TURN server. Works through any NAT/firewall but adds latency. This is the fallback for users behind corporate firewalls or symmetric NATs.

   The ICE framework automatically discovers the best available path and negotiates the connection, but configuration matters - TURN servers must be geographically close to users to minimize relay latency.

3. ›

   Connection Health Monitoring: After the connection is established, the system polls WebRTC's getStats() API at regular intervals, tracking:

   • ›Round-trip time: Latency between peers. Above 300ms, conversation feels unnatural.
   • ›Packet loss: Above 5%, audio becomes choppy. Above 15%, video artifacts appear.
   • ›Available outgoing bandwidth: Determines whether the connection can sustain the current video quality.

   When metrics cross thresholds, the system takes progressive action: first attempt ICE restart (re-negotiate the connection path), then reduce video resolution, then switch to audio-only, and finally notify users of persistent issues.

4. ›

   Session Recovery: If the connection drops entirely (both peers lose the media stream), the system initiates an automatic reconnect sequence: a new SDP offer/answer exchange through the existing Firestore document, with fresh ICE candidate gathering. The UI shows a "Reconnecting..." state with a progress indicator. If reconnection succeeds within 30 seconds, the session continues. If not, both users are offered the option to retry or reschedule.

5. ›

   Fallback to Server-Relayed Communication: For environments where even TURN relay fails (extremely restrictive corporate proxies), the system provides a text-based chat fallback with audio via a phone bridge as a last resort. While not the full video experience, it preserves the session's value rather than canceling entirely.

Why this matters: Most WebRTC tutorials show the happy path - two peers on good connections establishing a direct stream. Production video calling requires handling the unhappy paths: NATs that reject direct connections, bandwidth that drops mid-session, users on mobile networks that hand off between towers. The difference between a demo and a product is the quality of the failure handling.

Key Challenges & Solutions

• ›

  Challenge: WebRTC peer-to-peer connections fail silently behind certain NAT configurations (symmetric NATs, enterprise firewalls) without informing the application why. Approach: Configured TURN relay servers as mandatory fallback candidates in the ICE configuration. The system attempts direct connections first (STUN-based) but automatically falls back to relay when direct paths fail. Connection path selection is logged for debugging. Why: Requiring direct peer-to-peer connections would exclude users behind corporate networks and certain mobile carriers. TURN relay adds slight latency but ensures universal connectivity.

• ›

  Challenge: Payment confirmation and session scheduling must be atomic - a paid session must result in a booked time slot, and a cancelled session must result in a refund. But the client, Stripe, and Firebase are separate systems with no shared transaction. Approach: Used Stripe webhooks processed by Cloud Functions as the source of truth for payment status. The webhook handler atomically updates Firestore (mark session as confirmed, update mentor availability) within a Firestore transaction. Refunds follow the same pattern - Stripe webhook triggers the Cloud Function that reverses the booking state. Why: Client-side payment confirmation is unreliable (browser can disconnect). Server-side webhook processing ensures consistency regardless of client state, and Firestore transactions ensure the booking state update is atomic.

• ›

  Challenge: Real-time mentor availability must reflect actual current state - if a mentor starts a session, they should immediately disappear from search results for other candidates. Approach: Mentor availability is stored as a Firestore document that updates in real-time. When a session begins, a Cloud Function updates the mentor's availability document. All candidates browsing the mentor directory receive this update through Firestore's real-time listeners within seconds. Why: Polling-based availability checks would show stale data during the poll interval, leading to frustrating double-booking scenarios. Firestore's real-time synchronization ensures availability state is always current across all connected clients.

• ›

  Challenge: The interview preparation context creates user anxiety - aggressive loading spinners, abrupt transitions, and clinical UI language amplify stress rather than facilitating productive practice. Approach: Designed a motion and visual language system specifically for the coaching context - gentle loading animations, smooth page transitions, warm color palette, encouraging microcopy, and a deliberate "breathing" transition before video sessions activate. Why: In a coaching product, the UI is part of the coaching experience. Motion design and visual language that reduce anxiety directly improve the quality of practice sessions. This isn't aesthetic preference - it's functional UX that serves the product's core goal of building candidate confidence.

Outcomes

• ›Session reliability: STUN/TURN fallback, ICE restart, and graceful degradation keep video sessions stable across residential WiFi, mobile networks, and corporate firewalls.
• ›Booking integrity: Stripe webhooks processed by Cloud Functions keep payment and booking state consistent even if the browser disconnects mid-payment.
• ›Mentor ecosystem: Real-time availability and streamlined booking let mentors run their coaching practice with scheduling, payments, and logistics handled.
• ›Cross-device access: Responsive layouts let candidates join from phones, tablets, and desktops.

Engineering Takeaways

Coffee Tea demonstrated the technical challenges of synchronous product design. When the core product is a live session, reliability and latency aren't just metrics - they are the user experience. A dropped frame during a mock interview has more impact than a slow page load on an e-commerce site.

Patterns I'd reuse:

• ›Firebase as a WebRTC signaling layer. Firestore's real-time document listeners provide exactly the semantics needed for SDP and ICE candidate exchange, eliminating the need for custom WebSocket signaling infrastructure.
• ›Cloud Functions for payment webhook processing. Decoupling payment confirmation from the client ensures transactional consistency regardless of client state.
• ›Motion design as functional UX (not decoration). In products where user psychology matters (coaching, healthcare, education), animation serves a purpose beyond aesthetics.

What I'd reconsider:

• ›Firestore's real-time listeners are powerful but create persistent connections per active listener. At scale with many concurrent mentor browsing sessions, this could create cost pressure. A future iteration might batch availability updates or use a more efficient pub/sub mechanism for the mentor directory.
• ›The current TURN server configuration uses a single provider. For production scale, multiple TURN server providers across geographic regions would reduce relay latency for international sessions.

Trade-offs acknowledged:

• ›Chose Firebase (Firestore + Cloud Functions) over a custom Node.js backend, accepting vendor dependency and per-operation pricing in exchange for managed real-time infrastructure and serverless scaling.
• ›Chose WebRTC peer-to-peer over server-mediated video (like a selective forwarding unit), accepting the NAT traversal complexity in exchange for lower latency and no server-side media processing costs.
• ›Chose Framer Motion for animations over CSS-only transitions, accepting the bundle size addition in exchange for declarative animation composition and physics-based motion that CSS transitions can't easily replicate.