Builder

An AI product manager that joins your Google Meet, asks the right questions, and builds a clickable prototype while your team decides.

Comment

Inspiration

Product meetings end with notes and a promise to "mock it up." The mockup shows up days later, and by then half the room remembers the decisions differently. The meeting where the ideas were clearest left nothing anyone could click.

We wanted the meeting itself to produce the prototype, built from what people actually said, while everyone is still there to correct it.

What it does

Builder joins a Google Meet as a participant and screenshares a live stage. It works like a product manager in the room, not a note taker:

  • It asks first. It opens by asking what the app is and who it's for. Then it stays quiet unless someone addresses it, the room gets stuck, or a decision needs confirming.
  • It builds while you talk. A clickable phone or web prototype appears as people describe it.
  • It turns disagreement into a choice. When people disagree, it shows the options side by side as A and B, each with its trade-off and who backed it. Someone says "I'd go with B," and B becomes the app.
  • It only records agreement that people gave. A decision becomes agreed when another participant supports it out loud, or when nobody objects for 30 seconds. Every agreement cites the transcript lines behind it, and the model can't mark anything agreed on its own.
  • It ends with a handoff page: the decision log (who proposed what, who agreed, what lost), open questions, the component spec and the clickable prototype, exportable as one HTML file.

Teams use the web app or the mobile app, work inside organizations, invite teammates, see their sessions with live status, and start a session by pasting a meeting link.

How we built it

A TypeScript monorepo with four apps and two shared packages:

  • engine: runs the meeting. It controls the bot, reads the live transcript, and runs a fast conversation loop (when to speak) and a build loop (which updates the decision record and the prototype in small, validated patches). It also serves the stage and the handoff page.
  • api: accounts, organizations, sessions and limits. It calls the engine over a private network.
  • web (React, Vite, Tailwind) and mobile (Expo).
  • contracts (zod schemas for everything that crosses an app boundary) and session-core (session logic shared by web and mobile).

Partner platforms

Clerk handles identity on web and mobile. Each company is a Clerk organization, which is our tenant: the api reads the organization only from the verified Clerk token, never from the request, and scopes every query to it. Admins invite teammates with Clerk's built-in team invitations and roles. People sign in with email, phone or Google, and sign-up has bot protection. One Clerk login works across the web app, the mobile app and the api.

Expo (SDK 57, Expo Router) runs our mobile app. Users sign in, switch organizations, see their sessions and start a new one from their phone, using the same shared session logic as the web app. EAS Build produces our Android APK, and EAS Update publishes previews.

SurrealDB stores everything: transcripts, decisions, prototypes, sessions and organizations. In production, the engine and the api each sign in to SurrealDB Cloud as a user of their own database only, so the api can't read transcripts. Start limits run inside SurrealDB transactions, so simultaneous requests can't send extra paid bots. Tests and local mode run SurrealDB in-process.

Other key technologies

  • Recall.ai: the meeting bot, low-latency per-speaker transcription, signed webhooks, and screensharing our stage into the call.
  • Claude (through OpenRouter): Haiku 5.5 for conversation, Sonnet 5.5 for building.
  • ElevenLabs (through OpenRouter) gives Builder its voice; if someone interrupts, it stops talking.
  • Render runs all services and deploys from main after CI passes.

Security and ethics

  • The bot is always a visible participant and posts a pinned message saying it's transcribing.
  • Each organization's data is isolated, enforced from the verified token on every request.
  • Per-session spend and time limits, plus caps per organization and per person, keep costs bounded.
  • People decide: the model can never mark a decision as agreed by itself.

Challenges we ran into

  • Hearing "B" reliably. The live transcript has no capitals or punctuation. "B" must resolve the choice, but "maybe B," "not B," "B, then A" or the article "a" must not. We built a dedicated matcher and tested it by replaying a full scripted meeting until it passed three runs in a row against the live models.
  • Never sending two paid bots. A double-click or a retry costs money. The api reuses the organization's active session for the same meeting, saves a record before calling the engine, and never retries the call.
  • Keeping organizations apart. Mobile tokens have no browser origin, so we had to accept them without weakening the origin check for browsers.
  • Keeping the model honest. Early versions could change an agreed screen without a new decision, so we moved those rules out of the prompt and into code.

Accomplishments that we're proud of

  • A full meeting runs end to end with the live models: opening, disagreement, spoken pick, handoff.
  • Every agreement on record traces back to what people said.
  • One product on web and phone, with shared logic.
  • Costs stay bounded with limits per session, organization and person.

What we learned

  • For a rule like "nothing is agreed unless someone said it," code is far more reliable than a prompt.
  • Most of the work in a meeting agent is knowing when not to act.
  • Anything that costs money should happen once, after a record exists.
  • Two options side by side settle a disagreement faster than any summary.

What's next for Builder

  • Memory across meetings, so the next meeting picks up where the last one ended
  • More proactive product-manager behavior, like challenging ideas before building them
  • Billing with plans and metered meeting minutes
  • Calendar scheduling, an iOS build and a production domain

Prior work and scaffolding

Everything was built during build week (Oct 16–25, 2026); the first commit was made after build week started. No starter template was used. Assets: 40 Unsplash photos (Unsplash License, credited in the repo), Lucide icons, and the open-source fonts Inter, Fraunces and Schibsted Grotesk. We used Claude Code as a coding assistant throughout.

Built With

Share this project:

Updates

Submission history