Building a Real-Time Voice SaaS With Gemini Live API — Full Implementation With Stripe Billing

Step 1: Open the Gemini Live WebSocket Connection

Start with the connection layer.

// src/lib/gemini-live-client.ts
import WebSocket from "ws";
 
export interface GeminiLiveConfig {
  apiKey: string;
  model?: string;
  systemInstruction?: string;
}
 
export class GeminiLiveClient {
  private ws: WebSocket | null = null;
  private config: GeminiLiveConfig;
  private onAudioCallback: ((audio: ArrayBuffer) => void) | null = null;
 
  constructor(config: GeminiLiveConfig) {
    this.config = config;
  }
 
  async connect(): Promise<void> {
    const url = `wss://generativelanguage.googleapis.com/ws/google.ai.generativelanguage.v1beta.GenerativeService.BidiGenerateContent?key=${this.config.apiKey}`;
    this.ws = new WebSocket(url);
 
    return new Promise((resolve, reject) => {
      this.ws!.on("open", () => {
        // Send the initial setup message
        this.ws!.send(JSON.stringify({
          setup: {
            model: `models/${this.config.model ?? "gemini-2.5-flash-live"}`,
            generation_config: {
              response_modalities: ["AUDIO"],
              speech_config: {
                voice_config: { prebuilt_voice_config: { voice_name: "Aoede" } }
              }
            },
            system_instruction: this.config.systemInstruction
              ? { parts: [{ text: this.config.systemInstruction }] }
              : undefined,
          }
        }));
        resolve();
      });
      this.ws!.on("error", reject);
      this.ws!.on("message", (data: Buffer) => {
        const msg = JSON.parse(data.toString());
        if (msg.serverContent?.modelTurn?.parts?.[0]?.inlineData?.data) {
          const audio = Buffer.from(msg.serverContent.modelTurn.parts[0].inlineData.data, "base64");
          this.onAudioCallback?.(audio.buffer);
        }
      });
    });
  }
 
  sendAudio(audioChunk: ArrayBuffer): void {
    if (!this.ws || this.ws.readyState !== WebSocket.OPEN) return;
    const base64Audio = Buffer.from(audioChunk).toString("base64");
    this.ws.send(JSON.stringify({
      realtime_input: {
        media_chunks: [{
          mime_type: "audio/pcm;rate=16000",
          data: base64Audio
        }]
      }
    }));
  }
 
  onAudio(callback: (audio: ArrayBuffer) => void): void {
    this.onAudioCallback = callback;
  }
 
  close(): void {
    this.ws?.close();
  }
}

The key piece is the initial setup message specifying response_modalities: ["AUDIO"] — that's what tells Gemini to respond with audio rather than text.

voice_name selects from Google's pre-built voices. "Aoede" is a soft, neutral voice; "Charon" is a deeper male voice. Pick what fits your product personality.

Step 2: Build the WebSocket Gateway in Cloudflare Workers

Now build the gateway that accepts WebSocket connections from clients (browsers or mobile apps) and proxies to Gemini Live API. Durable Objects are ideal here.

// src/durable-objects/voice-session.ts
import { DurableObject } from "cloudflare:workers";
import { GeminiLiveClient } from "../lib/gemini-live-client";
 
export class VoiceSession extends DurableObject {
  private clientWs: WebSocket | null = null;
  private geminiClient: GeminiLiveClient | null = null;
  private startTime: number = 0;
  private userId: string = "";
  private stripeCustomerId: string = "";
 
  async fetch(req: Request): Promise<Response> {
    const url = new URL(req.url);
    this.userId = url.searchParams.get("userId") ?? "";
    this.stripeCustomerId = url.searchParams.get("customerId") ?? "";
 
    const upgradeHeader = req.headers.get("Upgrade");
    if (upgradeHeader !== "websocket") {
      return new Response("Expected WebSocket", { status: 400 });
    }
 
    const { 0: client, 1: server } = new WebSocketPair();
    server.accept();
    this.clientWs = server;
 
    // Initialize the Gemini Live client
    this.geminiClient = new GeminiLiveClient({
      apiKey: this.env.GEMINI_API_KEY,
      systemInstruction: "You are a helpful customer support agent.",
    });
    await this.geminiClient.connect();
 
    // Forward Gemini's audio responses to the client
    this.geminiClient.onAudio((audio) => {
      this.clientWs?.send(audio);
    });
 
    // Forward client audio to Gemini
    server.addEventListener("message", (event) => {
      if (event.data instanceof ArrayBuffer) {
        this.geminiClient?.sendAudio(event.data);
      }
    });
 
    // Bill on session close
    server.addEventListener("close", async () => {
      const durationSeconds = Math.ceil((Date.now() - this.startTime) / 1000);
      await this.recordUsage(durationSeconds);
      this.geminiClient?.close();
    });
 
    this.startTime = Date.now();
    return new Response(null, { status: 101, webSocket: client });
  }
 
  private async recordUsage(durationSeconds: number) {
    await fetch("https://internal.api/record-voice-usage", {
      method: "POST",
      headers: { "Content-Type": "application/json" },
      body: JSON.stringify({
        customerId: this.stripeCustomerId,
        userId: this.userId,
        durationSeconds,
        sessionId: this.ctx.id.toString(),
      }),
    });
  }
}

Why Durable Objects? They guarantee state for the duration of the WebSocket session. Standard Cloudflare Workers struggle with cross-request state, which doesn't work for continuous data like audio.

Step 3: Bill Call Duration Through Stripe Meter Events

When the session ends, send the total duration in seconds to Stripe Meter Events. This enables per-second billing — for example, "$0.001 per second."

// src/lib/voice-billing.ts
import Stripe from "stripe";
 
export async function recordVoiceUsage(args: {
  customerId: string;
  userId: string;
  durationSeconds: number;
  sessionId: string; // used as the idempotency key
}) {
  const stripe = new Stripe(process.env.STRIPE_SECRET_KEY!, {
    apiVersion: "2024-10-28.acacia",
  });
 
  // Don't bill extremely short calls — treat them as connection failures
  if (args.durationSeconds < 3) {
    console.log(`Session ${args.sessionId} too short, skipping billing`);
    return null;
  }
 
  // Send to Meter Events
  try {
    const event = await stripe.billing.meterEvents.create({
      event_name: "voice_call_seconds",
      payload: {
        stripe_customer_id: args.customerId,
        seconds: args.durationSeconds.toString(),
      },
      identifier: args.sessionId,
    });
    console.log(`Billed ${args.durationSeconds}s for ${args.userId}`);
    return event;
  } catch (err) {
    console.error("Meter event failed", err);
    await saveToDLQ(args);
    return null;
  }
}

Excluding short calls is important. Connection failures often produce sub-second "calls," and billing for those is a fast track to user complaints. Three seconds is the threshold I've settled on after running this in production. The session ID doubling as the Stripe idempotency key is what keeps retries from double-charging; I cover that pattern in depth in the idempotency key design for the Gemini API.

Step 4: Client-Side Implementation (Browser)

In the browser, capture mic audio via MediaRecorder and stream it through WebSocket. Play response audio via AudioContext.

// public/voice-client.ts
class VoiceClient {
  private ws: WebSocket | null = null;
  private mediaRecorder: MediaRecorder | null = null;
  private audioContext: AudioContext | null = null;
 
  async startCall(userId: string, customerId: string) {
    // Request microphone permission
    const stream = await navigator.mediaDevices.getUserMedia({ audio: true });
 
    // Open WebSocket
    this.ws = new WebSocket(`wss://api.example.com/voice?userId=${userId}&customerId=${customerId}`);
    this.ws.binaryType = "arraybuffer";
 
    this.audioContext = new AudioContext({ sampleRate: 16000 });
 
    // Play audio coming from the server
    this.ws.addEventListener("message", async (event) => {
      if (event.data instanceof ArrayBuffer) {
        const audioBuffer = await this.audioContext!.decodeAudioData(event.data);
        const source = this.audioContext!.createBufferSource();
        source.buffer = audioBuffer;
        source.connect(this.audioContext!.destination);
        source.start();
      }
    });
 
    // Stream mic audio over the WebSocket
    this.mediaRecorder = new MediaRecorder(stream, { mimeType: "audio/webm" });
    this.mediaRecorder.ondataavailable = async (e) => {
      if (e.data.size > 0 && this.ws?.readyState === WebSocket.OPEN) {
        const arrayBuffer = await e.data.arrayBuffer();
        this.ws.send(arrayBuffer);
      }
    };
    // 100ms intervals minimize perceived latency
    this.mediaRecorder.start(100);
  }
 
  endCall() {
    this.mediaRecorder?.stop();
    this.ws?.close();
    this.audioContext?.close();
  }
}

MediaRecorder.start(100) controls the chunk interval. Sending 100ms of audio at a time minimizes the delay from "user speaks" to "AI responds." Going lower increases WebSocket traffic; 100ms is a practical sweet spot.

Step 5: Tuning Voice Quality vs. Cost

Gemini Live API gives you several knobs to trade quality for cost: sampling rate, codec, model.

My recommended settings:

• Sample rate: 16kHz (telephone quality, lowest cost)
• Model: gemini-2.5-flash-live (about 3× cheaper than Pro Live)
• Response audio format: PCM 24kHz (clear playback)
• VAD (Voice Activity Detection): enabled (suppress token consumption during silence)

This lands per-minute cost around $0.05–$0.10. If you charge users $0.30/minute, gross margin sits in the 60–80% range.

Step 6: Monitoring — What to Watch

Four metrics are non-negotiable for voice SaaS operations.

Connection failure rate: what percentage of WebSocket attempts can't establish? Above 5%, something is wrong.

Average call length: very long sessions (10+ minutes) often mean users forgot to disconnect. Consider auto-disconnect logic.

Per-minute unit cost: cross-check Google Cloud invoices against your call duration data. Drift away from your model is a red flag.

Response latency: time from client send to response received. Aim for under 300ms.

Push these to Cloudflare Analytics Engine or BigQuery, then visualize in Looker Studio or similar.

Common Pitfalls

A few traps that catch developers building on this stack:

Trap 1: Billing leaks on abrupt disconnect

If the client drops abruptly (network failure), the close event may not fire. Use Durable Objects' alarm to force-terminate after a timeout of message inactivity.

Trap 2: Audio format mismatch

Gemini Live API expects audio/pcm;rate=16000. Sending raw WebM produces silent responses. Server-side WebM-to-PCM conversion may be needed.

Trap 3: Forgetting VAD

Without VAD enabled, every silent moment is billed at full token rate. On long calls this can 2–3× your costs.

Trap 4: Missing idempotency on Meter Events

If you don't pass session ID as identifier, retries can double-charge. Durable Object IDs are perfect natural keys — use them.

Trap 5: AudioContext memory leak in the client

Forgetting audioContext.close() slowly leaks browser memory. Critical for apps where users have long sessions.

Hybrid Plan Design — Time + Flat Subscription

Here's the plan structure I recommend:

• Free: 10 minutes/month, then no calls
• Standard: $15/month + 60 minutes included + $0.30/minute overage
• Pro: $50/month + 300 minutes included + $0.20/minute overage
• Enterprise: $200/month + 1500 minutes included + $0.15/minute overage

Higher tiers come with cheaper overage rates, naturally pulling heavy users upward. With Gemini Live API costs in mind, Standard hits ~60% gross margin and Enterprise reaches ~70%.

For a deeper pricing strategy walkthrough, see the full guide on profitable Gemini API micro-SaaS.

Summary — Starting Point for a Voice SaaS

Don't try to ship all six steps at once. I started by getting "Step 1: a single round-trip of audio with Gemini" working — minimal client, minimal server, just to confirm Gemini responds.

From there, layer on Cloudflare Workers deployment, Stripe wiring, the client implementation, and operational monitoring. A realistic pace is one week to MVP and three weeks to production-ready.

Voice SaaS becomes irreplaceable the moment "natural conversation with low waiting time" actually works. The technical bar is still high, but Gemini Live API has finally made it a domain solo developers can attack.

Operational Lessons From Real Deployment

After a month of production traffic, several non-obvious lessons emerged that aren't in any documentation.

The first lesson: the first 30 seconds of a call dominate user perception. If the AI response feels even slightly off — wrong tone, slight delay, awkward greeting — users hang up before the conversation properly starts. Spend disproportionate effort on the opening exchange. A pre-loaded greeting played the moment connection establishes, while Gemini Live initializes in the background, fixes most of this.

The second lesson: users will speak over the AI, and your code needs to handle interruption gracefully. Without explicit interruption handling, the AI keeps talking while the user tries to redirect, producing a frustrating experience. Gemini Live API has built-in support for interruption via client_content messages — wire that into the WebSocket gateway from day one.

The third lesson: measure cost per active user, not cost per call. A user who makes one 30-minute call costs differently from a user who makes thirty 1-minute calls, and pricing pages need to reflect that. Build a dashboard that shows active users by usage tier and adjust your plan tiers based on what you see.

The fourth lesson: add a "billing summary" notification at session end. Users who can see "this call cost $0.45, monthly total $3.12" trust the billing far more than users who only see a monthly invoice. A small WebSocket message at the end of each session, displayed briefly in the UI, creates this trust without requiring a custom dashboard.

The fifth lesson: language detection matters more than expected. Users will sometimes start in one language and switch mid-conversation. Gemini Live handles this gracefully on its end, but your system instruction should explicitly authorize language switching. Otherwise you may get unexpected refusals or stiff responses.

These five together represent maybe two months of incremental learning. Start with the basics, deploy to a small group of friendly testers, and iterate on these specific points before wider release. If you want per-session traces to debug these issues, the approach in the Langfuse observability guide for the Gemini API works directly on voice sessions too.

Final Pre-Launch Checklist

Before you announce a voice SaaS publicly, walk through these six items:

First, latency benchmarking. Measure p50 and p95 latency from at least three geographic regions. If p95 exceeds 500ms anywhere, investigate before launching there.

Second, billing reconciliation. Run a synthetic call every hour for 24 hours and verify the Meter Events arrive correctly. Cross-check against the test invoice.

Third, abuse handling. What happens if a user opens 10 simultaneous sessions? Enforce per-user concurrent session limits — Durable Objects make this trivial.

Fourth, transcript privacy. Confirm with users at session start whether transcripts are stored. Have a clear policy and surface it in the UI.

Fifth, fallback path. If Gemini Live API has an outage, do you fall back to a slower path (Whisper + GPT) or simply queue with apologies? Decide and document.

Sixth, quota monitoring. Google Cloud has soft quotas on Gemini Live API. Know your current quota and what to do when you approach 80%. For trimming the non-voice portion of your bill, the techniques in the Gemini API caching strategy apply to any companion features you bundle in.

Once these six are clear, you're ready to ship. The first satisfied user who finishes a call and converts to a paid plan validates the entire architecture.

Scaling Beyond a Single Region

When initial traffic is regional, a single Cloudflare Workers deployment serving the closest data center is fine. As you grow internationally, however, voice latency becomes the dominant differentiator between perceived service quality.

The architecture I recommend for multi-region voice SaaS hinges on two principles. First, terminate WebSocket connections at the geographically nearest edge — Cloudflare Workers does this automatically, but verify with logging that connections actually land where you expect. Second, cache Gemini Live API connection capability checks in regional KV; without this, a sudden cold-start across all edges produces correlated latency spikes whenever Google rotates infrastructure.

A subtler issue: Gemini Live API endpoints themselves have regional capacity. Sending traffic from a Cloudflare edge in São Paulo to a Gemini endpoint provisioned only in us-central1 produces an extra 150ms of round-trip latency. Track which Gemini endpoints serve your region and route accordingly. For users in regions far from any Gemini endpoint, expect a permanent 100–200ms latency floor that no amount of code optimization will fix.

Multi-region also affects billing. Stripe accounts are global, but if you have local pricing (yen for Japanese users, euros for European), each Stripe Customer must be configured with their currency before the first Meter Event. Mid-stream currency changes are not supported.

Transcript Storage and Search Capabilities

Roughly two-thirds of voice SaaS use cases benefit from making conversation transcripts searchable. Customer support agents review past calls; sales teams analyze conversion patterns; users want to revisit what was said three weeks ago.

Gemini Live API provides transcripts as a side channel — request the text modality alongside audio in the response configuration to get parallel text streams. Store these in a separate datastore (Cloudflare D1 or a dedicated PostgreSQL instance) keyed by session ID, with full-text search enabled.

The non-obvious complexity here is privacy. Voice conversations often include sensitive content users wouldn't write in chat. Surface "transcripts are stored for X days, then automatically deleted" in plain language at session start, not buried in terms of service. Build deletion controls into the user-facing dashboard. The trust dividend is significant.

Compliance frameworks (GDPR, HIPAA, SOC 2) impose specific requirements on voice data — retention windows, encryption at rest, access logging, data residency. None of those are technically hard, but they need to be designed in from the beginning rather than retrofitted under audit pressure.

Wrapping up — Your First Production Voice Conversation

The path from "I want to build a voice SaaS" to "I have a paying user who just hung up satisfied" is shorter today than at any previous moment. Gemini Live API removed the latency wall; Cloudflare Workers Durable Objects removed the infrastructure wall; Stripe Meter Events removed the billing wall. What remains is the product work.

Start with the absolute minimum: WebSocket connection, one round-trip of audio, manual end-of-session billing in the test environment. That alone is two days of focused work. Layer on the rest at your own pace, and treat each working layer as a release candidate rather than a draft.

The first time a stranger pays you for a voice conversation with an AI you built — that's the milestone that transforms this from a technical exercise into a real business. Every layer of complexity above exists to support reaching that milestone reliably.

A Detailed Walkthrough — Day One Through Day Thirty

To make this concrete, here's what a thirty-day path from zero to production-ready voice SaaS actually looks like. Use it as a planning template rather than a strict schedule.

Days one through three: get a single round-trip of audio working between your local Node.js process and Gemini Live API. No client, no Stripe, no Cloudflare yet. The goal is simply to confirm the API works as documented and produce a recording showing input audio in, response audio out. Save that recording — you'll come back to it as a baseline reference.

Days four through seven: stand up the WebSocket gateway in Cloudflare Workers Durable Objects. Build a minimal browser client that connects, captures microphone input, and plays response audio. At the end of week one, two devices on different networks should be able to "call" your service and have a conversation with the AI.

Days eight through fourteen: layer in authentication and basic user accounts. The simplest path is integrating with an existing auth provider rather than building authentication from scratch. The point isn't perfect identity management yet — it's having user IDs to attach to sessions for billing.

Days fifteen through twenty-one: integrate Stripe. Create the meter, wire up Meter Events on session close, and validate end-to-end that a test call produces a draft invoice with the correct duration. This is the hardest week. Budget for it.

Days twenty-two through twenty-eight: add monitoring and admin tools. Connection failure rate, average call length, per-minute cost — these need dashboards before you can responsibly take payments. Build a small admin UI for issuing credit notes and adjusting subscriptions.

Days twenty-nine and thirty: invite five friendly testers, watch them use the service, and fix whatever breaks. The list of "what breaks" will surprise you — assume your assumptions are wrong about what's intuitive. After fixing the obvious issues, you're ready to expand to a public beta.

After thirty days, the architecture you've built supports scaling to thousands of monthly active users without major rework. The next ninety days are pricing experimentation and product iteration, not infrastructure rebuilds. That's the value of getting the architecture right up front.

Cost Modeling Across Plan Tiers

Let's run concrete unit economics for the four-tier hybrid plan I recommended. Assume Gemini Live Flash at roughly $0.07 per minute of conversation (input + output, with VAD enabled to suppress silent intervals).

For the Free tier at 10 minutes/month: cost $0.70 per active free user, revenue $0. Free users exist as a top-of-funnel acquisition channel, so model their cost against expected conversion rate. If 5% of free users convert to Standard, the effective acquisition cost per paid user is $0.70 × 20 = $14.00 — quite reasonable.

For Standard at $15/month: light user (40 minutes/month) costs $2.80, 81% gross margin. Average user (60 minutes, hits the included limit) costs $4.20, 72% gross margin. Heavy user (120 minutes, 60 minutes overage at $0.30/min = $18 additional revenue) — total revenue $33, total cost $8.40, 75% gross margin.

For Pro at $50/month: average user at 250 minutes costs $17.50, 65% gross margin. Heavy user at 600 minutes (300 minutes overage at $0.20/min = $60 additional) — total revenue $110, total cost $42, 62% gross margin.

For Enterprise at $200/month: typical organizational use at 1200 minutes/month costs $84, 58% gross margin. Heavy enterprise users (3000 minutes, 1500 minutes overage at $0.15/min = $225 additional) — total revenue $425, total cost $210, 51% gross margin.

The pattern: gross margins compress at higher tiers, but absolute dollar contribution increases substantially. Enterprise users at 51% margin still produce roughly $215 of contribution per month, versus $11 from a Standard average user. Both matter, but they matter for different reasons — Standard for predictable subscription revenue, Enterprise for revenue concentration.

Knowing these numbers cold lets you make pricing decisions confidently. If you're considering a 20% price drop on Standard, you can immediately calculate the impact: 81% margin drops to 76%, which is still healthy if it drives 25% more conversions. The math is what makes pricing changes safe.

Closing Thoughts on Architecture Choices

Some readers may wonder why I chose Cloudflare Workers Durable Objects over more traditional infrastructure. The honest answer is operational simplicity. Solo developers don't have the bandwidth to manage Kubernetes clusters or fine-tune autoscaling for WebSocket workloads. Durable Objects scale to demand transparently, charge per actual use, and survive deploy cycles without manual intervention. For a voice SaaS expecting unpredictable traffic patterns, that operational profile is worth more than raw throughput optimization.

Similarly, the choice of Gemini Live Flash over Pro is a deliberate cost trade. Pro has better voice quality and broader knowledge, but for the typical conversational AI use cases — customer support, coaching, language tutoring, meditation guidance — Flash is indistinguishable from Pro in user testing. Spend the savings on better infrastructure, faster iteration, or better marketing, rather than on incrementally better model quality the user never notices.

Stripe Meter Events were chosen for the reasons elaborated earlier, but worth restating: the alternative paths (Usage Records, Subscription Items with quantity updates, custom invoicing) all require more code and produce less reliable billing. Meter Events are designed for exactly this pattern, and Stripe's investment in the surface area continues to grow. Building on it is a long-term safe bet.

If any of these choices feel restrictive in your context, the architecture itself is portable. Replace Cloudflare Workers with AWS Lambda + DynamoDB Streams; the WebSocket handling logic translates with minor changes. Replace Gemini Live Flash with Gemini Live Pro for premium tiers; only the model name changes. The five-layer separation that's been the spine of this article holds regardless of specific platform choices.

Build small, ship fast, iterate on real user feedback. The architecture lets you do that without inheriting limitations later. That's what makes this approach worth the upfront design effort.

The voice SaaS market is at the same point chat-based SaaS occupied around 2022 — the technology has matured enough that small teams can build credible products, and the field is still wide open for differentiation. Pick a clear use case, build the simplest version that delivers value, and let real users tell you what to build next.