DEV Community: Ayush Barai

MeetBrief AI : turns spoken discussions into structured, shareable meeting intelligence reports.

Ayush Barai — Mon, 26 Oct 2026 04:46:29 +0000

This is a submission for the Hacktoberfest Open-Source AI Challenge Week 3: Slow and Steady.

Picture the twenty minutes after a 40-minute launch call. The call is over. The decisions are not. You open a blank document and try to remember what was actually agreed.

The recording has the answer. It always does. The problem is that the recording is 40 minutes long, and you are tired.

That gap — between a conversation and the record of it — is where most meeting tools make things worse. They hand you a confident paragraph with no receipts. It reads well. It might even be right. But when someone asks who agreed to the 14-day trial, or why a task landed on their plate, the summary has nothing to show.

MeetBrief AI closes that gap. It turns a recording into a transcript, an evidence-linked report, assigned action items, and a spoken recap you can listen to on the way home.

The recap is the part I want to spend time on. Giving a meeting a voice is easy now. Giving it a voice that cannot invent things is the interesting problem.

![MeetBrief AI — Your meeting ended. Your recap can prove it.]

What I Built

MeetBrief is a Next.js 15 PWA for the twenty minutes after a meeting.

You upload a recording or record in the browser, confirm consent, and the app transcribes it with a self-hosted open-source Whisper server. Gemma then turns the transcript into a structured report: purpose, outcomes, discussion points, decisions, owners, deadlines, open questions, and a next-meeting agenda.

Then you can rename the anonymous speakers, generate a spoken recap with ElevenLabs, share a read-only link, or export Markdown.

There is no attendee list and no manual participant entry. Diarization gives you Person 1, Person 2, and so on. A real name is applied only when a human confirms it. The AI may suggest a name, but only when that speaker explicitly introduced themselves in their own transcript line — and even then, it waits for a click.

The lazy payoff is simple: you leave the call and the first draft of the record already exists. Not a vibe summary. A document where every decision and task has a timestamp and a quote behind it.

Demo

The fastest way to see it is the /demo route. It is a complete interactive report — overview, transcript, decisions, actions, and recap — with no account, no recording, and no AI request.

git clone https://github.com/Ayush-Barai/MeetBrief
cd MeetBrief
npm install
npm run dev
# open http://localhost:3000/demo

The demo data is fictional and labeled as such everywhere. The screenshots below come from a real production build with the integrations intentionally unconfigured, so the UI is showing the actual product, not a mockup.

There is no public deployment yet. The /demo route is deliberately credential-free, so you can see the whole UI without a database or an API key; the full pipeline is in DEPLOYMENT.md.

The report workspace

The overview keeps the executive summary separate from the evidence. Tabs for transcript, decisions, action items, and the audio recap sit above the report instead of hiding in a sidebar.

![MeetBrief demo report overview]

No attendee list

You add a title, choose a language, upload a recording or record in the browser, and confirm consent. That is the whole setup. Speakers are discovered after transcription.

![Create a meeting without entering participants]

Speakers are anonymous until you say otherwise

The speaker panel shows Person 1 through Person 4, their segment counts, when they first spoke, and any AI suggestion that still needs confirmation.

The suggestion is not a rename. It is a hint stored separately from the transcript. Nothing changes until a human clicks.

![Speaker panel with anonymous labels and AI suggestions]

The transcript keeps the same labels, timestamps, and the transcription metadata: whisper (demo) · large-v3-turbo · diarized speaker labels.

![Transcript with Person labels and timestamps]

Decisions keep their uncertainty

A meeting record should not flatten “we agreed” and “we might agree” into the same sentence. Confirmed and tentative decisions look different, and each one carries the quote it came from.

![Decisions with evidence quotes]

Action items with real owners only

Owners and deadlines appear only when the transcript supports them. Otherwise the item is unassigned or the date is absent. Status can be updated as work moves.

![Action items with owners, deadlines, and evidence]

The Rule: The Model Proposes, The Transcript Decides

Most AI meeting notes trust the model’s output. I don’t.

Gemma returns structured JSON with segment IDs and quotes. Before anything is saved, the server checks it:

Zod validates the shape of the response.
Every cited segment ID must exist in the transcript.
Every quote must actually appear in that segment. If the ID is wrong but the quote is real, the server searches for the matching segment.
Evidence that cannot be verified is removed.
An owner the transcript doesn’t support — and who isn’t a known speaker — is reset to Unassigned.
A deadline without support in the transcript becomes Not specified.
A claim that loses all of its evidence stays in the report — with a visible warning. It is not silently deleted.

That last rule matters. Deleting a questionable decision hides the disagreement. Keeping it with a warning tells you exactly where to look.

Here is the core of the check:

for (const reference of evidence) {
  let segment = byId.get(reference.segmentId);

  if (!segment && reference.quote.trim().length > 12) {
    const needle = reference.quote.trim().toLowerCase().slice(0, 80);
    segment = segments.find((candidate) =>
      candidate.text.toLowerCase().includes(needle),
    );
  }

  if (!segment) {
    warnings.push(`${claimLabel}: a cited segment could not be verified and was removed.`);
    continue;
  }

  const quoteIsExact = segment.text
    .toLowerCase()
    .includes(reference.quote.trim().toLowerCase());

  results.push({
    segmentId: segment.id,
    timestampSeconds: segment.startSeconds,
    quote: quoteIsExact ? reference.quote.trim() : segment.text.slice(0, 277),
  });
}

The result is a report that can be incomplete. It can say “a decision had no verifiable transcript evidence.” It cannot confidently invent a decision.

I think that trade is the whole product.

Giving the Agent a Voice

This is my entry for Best Use of ElevenLabs: the open-source agent gets a voice, and the voice is constrained by the same evidence rules as the text.

The recap is not text-to-speech over the transcript. It is a deterministic script built from the reconciled report:

The meeting title and purpose.
Up to four key outcomes and takeaways.
Up to five decisions, with tentative ones explicitly labeled as tentative.
Up to eight action items, each with its owner and deadline — or the fact that there isn’t one.
Up to four open questions.

Then ElevenLabs reads it.

That order is the design. The voice only says things that survived validation. If the report refuses a claim, the audio never speaks it.

Could I have used an open-source TTS model? Yes. I chose ElevenLabs because the recap is the one place where voice quality is the product, and a robotic read undermines the reason to listen. The trade-off is explicit: the intelligence and the evidence stay open and self-hostable; the last mile is a hosted service I can swap out without touching the pipeline.

![Audio recap script built from the edited report]

The integration is deliberately boring in the places that should be boring:

const response = await fetch(
  `https://api.elevenlabs.io/v1/text-to-speech/${voiceId}?output_format=mp3_44100_128`,
  {
    method: "POST",
    headers: {
      "xi-api-key": config.elevenLabsKey,
      "Content-Type": "application/json",
      Accept: "audio/mpeg",
    },
    body: JSON.stringify({
      text: script,
      model_id: "eleven_multilingual_v2",
      voice_settings: {
        stability: 0.45,
        similarity_boost: 0.75,
        style: 0.2,
        use_speaker_boost: true,
      },
    }),
    signal: AbortSignal.timeout(120_000),
  },
);

The script is capped at 4,900 characters so a long meeting doesn’t turn into a failed request. The MP3 is written to GridFS, not stuffed into the meeting document. Generation is on demand, not part of the transcription job.

Two details I care about more than the voice settings:

Failure is not data loss. If ElevenLabs fails, the script is saved with status failed. You can read it, fix the report, and retry. The app never pretends audio exists.

The voice can go stale, and it says so. Rename a speaker or edit the report and the existing recap is marked stale:

if (recapScript && recapScript !== meeting.recap?.script) {
  await db.collection(COLLECTIONS.meetings).updateOne(
    { _id: meetingId },
    {
      $set: {
        "recap.script": recapScript,
        ...(meeting.recap?.status === "ready" ||
        meeting.recap?.status === "generating"
          ? { "recap.status": "stale" }
          : {}),
      },
    },
  );
}

The old MP3 is still there, but the UI tells you it no longer matches the record. A spoken recap that silently disagrees with the written one is worse than no recap at all.

That is what “giving an open-source agent a voice” means here: the voice is the last mile of an auditable pipeline, not a layer on top of a black box.

Code

The repository is public: https://github.com/Ayush-Barai/MeetBrief. It is a Next.js 15 / React 19 / TypeScript app with Zod validation, MongoDB 7, and Vitest. The files worth reading first:

lib/ai/report.ts — evidence reconciliation and speaker-suggestion checks
lib/elevenlabs/index.ts — recap script and text-to-speech
lib/transcription/whisper.ts — OpenAI-compatible adapter and diarization mapping
lib/speakers.ts — rename propagation across the report and action items
render.yaml + DEPLOYMENT.md — deployment

How I Built It

Open-source Whisper, self-hosted

The app talks to any OpenAI-compatible /audio/transcriptions endpoint. The recommended server is ScribeCrate (formerly docker-whisper, image hwdsl2/whisper-server), which wraps open-source faster-whisper and supports local speaker diarization.

docker run -d --name whisper \
  -p 9000:9000 \
  -e WHISPER_MODEL=large-v3-turbo \
  -e WHISPER_DIARIZATION=true \
  -v whisper-data:/var/lib/whisper \
  hwdsl2/whisper-server

When the server returns a speaker field per segment, MeetBrief maps those labels to stable Person N labels in first-seen order. If the server does not diarize, every segment is Person 1 and the transcript metadata says diarized: false. The app never invents speakers.

Gemma for structured analysis

Gemma is served through an OpenAI-compatible endpoint, so Ollama, vLLM, or a hosted Gemma endpoint all work:

GEMMA_API_URL=http://localhost:11434/v1
GEMMA_MODEL=gemma3:27b
GEMMA_TIMEOUT_MS=180000

The prompt asks for JSON with evidence segment IDs. The response is validated with Zod, then reconciled against the transcript before anything is saved. The model’s owners, deadlines, and dates are never trusted blindly.

MongoDB Atlas for the record

Atlas stores meeting metadata, ordered transcript segments, reports, action items, and share-token hashes. Recordings and recap MP3s live in the GridFS bucket meeting_files.

The MVP uses a signed, HTTP-only browser cookie for ownership. Every meeting read and write is scoped by userId on the server. Share links use 256-bit tokens; only the SHA-256 hash is stored, and links can be revoked.

ElevenLabs for the recap

Covered above. The important part is not the API call. It is that the script is generated from the report that already passed validation.

Render for deployment

The repository includes render.yaml:

Build: npm ci && npm run build
Start: npm run start
Health check: /api/health
Node 22

/api/health returns 200 ok only when MongoDB is configured and reachable. It returns 503 degraded otherwise, and it never exposes secrets.

The full Atlas + Whisper + Gemma + ElevenLabs + Render walkthrough is in DEPLOYMENT.md.

Why Open Innovation Matters

Three reasons, in the order they mattered to me.

The audio doesn’t have to leave. Meeting recordings contain pricing, hiring plans, legal risk, customer names, and things people said without expecting a transcript. Whisper can run on your laptop or your own VPS. Gemma can too. The sensitive input stays inside infrastructure you control.

The rules are inspectable. The prompt, the Zod schema, the evidence reconciliation, and the speaker-rename rules are all in the repository. If you disagree with how a claim is accepted, you can read the code and change it. That is much harder with a hosted pipeline that returns a confident paragraph and no trail.

The model is replaceable. Whisper is an endpoint. Gemma is an endpoint. You can trade model size for hardware, swap providers, or run everything locally without rewriting the product. The open pieces are not decoration — remove them and MeetBrief stops working.

A closed pipeline gives you a paragraph. An open one gives you a paragraph you can argue with.

And the theme fits: slow and steady is fine when the machine does the slow part. A 40-minute call can take three minutes to transcribe. The human shouldn’t have to spend twenty minutes rebuilding the record afterward. Slowness is only a virtue if it buys accuracy. Otherwise it is just latency.

My Agent Session

I used OpenCode during the build. I did not save a DevRelay session, so here is the short version.

The useful work was narrow and verifiable:

tracing every reference to the old transcription provider before removing it;
rewriting the Whisper adapter to parse optional diarization labels;
checking that speaker renames still propagate through reports, actions, exports, and the recap script;
updating the setup page, environment example, Render blueprint, and README;
running typecheck, tests, and a production build after each change.

The most instructive bug is a regex problem: "I'm Maya" and "Maya's idea" look identical to a naive pattern. The self-introduction check needs a real word boundary after the name; the test now pins it.

The human decisions stayed human: removing a proprietary speech provider, deciding what “open source” should mean for this project, and what the demo is allowed to claim.

The Lazy Payoff

The payoff I designed for is the twenty minutes after a call: no scrubbing a recording for a timestamp, no guessing who owns a task, no retyping decisions into a document.

I am not going to claim a measured team time saving. The demo is fictional and I did not run this with a team this week. What I can show is the workflow it removes — and the fact that the first draft arrives with receipts.

The next automation I would add is a durable processing queue. Right now processing runs through Next.js after(), which is fine for a demo but can be interrupted by a Render restart. A worker with a heartbeat and lease would make long meetings reliable. After that: real multi-user auth, a retention and deletion job, and per-user storage quotas.

What Is Real and What Is Demo

I want to be precise about the state of the project:

The demo report, transcript, speaker suggestions, and recap script are fictional and clearly labeled.
The screenshots were captured from a real local production build with integrations intentionally unconfigured.
The code paths for transcription, Gemma analysis, MongoDB persistence, and ElevenLabs recaps are implemented against real APIs.
The full end-to-end flow has not been executed in this workspace with live credentials. Missing configuration is surfaced in /setup, /api/health, and processing responses instead of being simulated.
Unit tests, TypeScript checks, and the production build pass locally.

That distinction matters. A demo should show the product honestly, not borrow credibility from an AI call that never happened.

![Setup page showing which integrations are configured]

Prize Categories

I would like this project considered for:

ElevenLabs — the open-source agent gets a voice, generated from the validated report, with failure handling and stale-audio detection.
Gemma — evidence-linked meeting analysis through an OpenAI-compatible Gemma endpoint, with Zod validation and transcript reconciliation.
MongoDB Atlas — meetings, transcript segments, reports, actions, share hashes, and GridFS audio in one managed database.
Render — a production-style Next.js deployment with a health check and a blueprint.

Try It

Repository: https://github.com/Ayush-Barai/MeetBrief

Start with /demo — no account, no recording, no API keys. If you want the real pipeline, DEPLOYMENT.md walks through Atlas, Whisper, Gemma, ElevenLabs, and Render.

If you have ever left a call unsure what was decided, I would love to know: what would your recap have to prove before you trusted it?

I built Simmer: an open-source AI agnet that turns cooking reels into recipes you can actually cook and ask questions about that recipe in real time

Ayush Barai — Mon, 19 Oct 2026 04:50:02 +0000

Simmer is an open-source AI recipe assistant. Share a cooking Reel, Short, or recipe link — or paste a recipe you already have — and it turns the mess into a clean recipe with ingredients, amounts, times, and ordered steps. Then it reads the steps to you and answers questions while your hands are busy.

The 20-second version

Problem: I save cooking reels every week and cook almost none of them. The recipe is split across a caption, a 45-second video, and a comment thread.
Product: Simmer turns that mess into a structured recipe, then becomes a hands-free cooking assistant.
Core AI: Gemma 4, open weights, for extraction, chat, and translation.
Inputs: Instagram, YouTube Shorts, recipe links, or pasted text.
Output: ingredients, amounts, times, tags, ordered steps, 10 languages, voice mode, installable PWA.
Traction: one paid early user. Small amount, real signal.

What I Built

Every week I save cooking reels I never cook.

The recipe is usually not in one place. The ingredients are in the caption. The method is in the audio. The quantities are in a comment. The video is 45 seconds of fast cuts and no measurements. By the time I’m hungry, rewriting all of that into something usable feels like homework.

Simmer is the step between saving and cooking.

You add a public link or paste text. Simmer reads the page, the caption, the metadata, and — if the text is useless — the audio. Then Gemma 4 turns that into a structured recipe: ingredients with amounts, ordered steps, times, servings, tags, and a title. Your original text is kept alongside it, so you can always check what the source actually said.

Then the app changes jobs. It becomes a cook-buddy:

It reads the steps out loud.
You can ask “how much salt?” without touching the screen.
It switches between 10 languages.
It installs as a PWA and opens from the share sheet.

The people I built this for are not professional chefs. They are people who save more recipes than they cook, people cooking in a second language, and anyone who has stood in a kitchen with wet hands trying to scroll back to step four.

The bet is simple: the input layer for recipes is broken. People already pay for recipe managers and meal planners. Simmer fixes the part before that — getting the recipe out of the feed and into a format you can cook from.

Demo

Live demo: simmer-live-demo-link

Video demo: Watch the 45-second demo

Images demo:

Code

Repo: github.com/Ayush-Barai/simmer — MIT licensed.

Ayush-Barai / simmer

Simmer

Share a cooking reel → get a clean recipe → cook hands-free with an open-AI buddy.

Built for the Hacktoberfest Open-Source AI Challenge (Week 2: Side Hustle).

What it does

Link → recipe: share a Reel/Short/TikTok or paste a link. Simmer reads the description first, then transcribes the audio if the text has no recipe; Gemma extracts ingredients, amounts, timings and ordered steps. You can also paste a recipe you already have — Simmer keeps your original wording and saves a clean, structured version.
Hands-free cooking: a live voice loop (ElevenLabs Conversational AI) with a browser speech fallback, so you can ask questions mid-step without touching the phone.
10 languages: read, chat and translate in English, Spanish, French, German, Italian Portuguese, Hindi, Japanese, Chinese and Arabic. Translations are saved with the recipe so switching language is instant.
Private cookbook: Clerk auth, per-user recipes, thumbnails and saved chat history.
…

View on GitHub

git clone https://github.com/Ayush-Barai/simmer.git
cd simmer
npm install
cp .env.example .env
npm run dev

Add your keys to .env — the README covers Gemma, MongoDB Atlas, Clerk, ElevenLabs, and Sentry.

The shape of the app:

link / pasted text
        │
        ▼
  page text + metadata
        │
        ├─ social caption / Instagram embed
        ├─ yt-dlp metadata + subtitles
        └─ ElevenLabs Scribe (audio fallback)
        │
        ▼
  Gemma 4 → structured recipe JSON
        │
        ▼
  MongoDB Atlas → PWA → cook mode / voice

How I Built It

1. Ingestion is a cascade, not a scraper

The hardest part is not the AI. It is getting clean text out of a link that was never designed to give it to you.

server/ingest.js tries the sources in order: page text and metadata, the social caption, the Instagram embed page, then yt-dlp for metadata and subtitles. If the description is empty or useless, server/transcript.js downloads the audio and server/stt.js sends it to ElevenLabs Scribe.

Each source fails differently. Instagram blocks one path but exposes another. A YouTube Short may have no captions. A recipe blog buries the ingredients under three popups. The cascade is the product.

2. Gemma 4 turns text into structure

server/gemma.js asks Gemma for strict JSON: title, ingredients, steps, times, servings, tags. It uses gemma-4-26b-a4b-it and gemma-4-31b-it, with a fallback list and a JSON repair path.

One bug cost me an afternoon: Gemma’s thinking output was being mixed into the response, which made valid recipes look empty. Filtering thought parts in both streaming and non-streaming responses fixed it. The model IDs are config, not hardcoded, so swapping models is an env-var change.

3. Translations are precomputed, not generated on click

Simmer supports 10 languages: English, Spanish, French, German, Italian, Portuguese, Hindi, Japanese, Chinese, and Arabic.

The first version translated on demand. It worked, but it felt slow and fragile: every language switch was another model call. Now server/localize.js prefetches the other nine languages in the background after a recipe is saved. Translations are stored in MongoDB with the recipe.

The result: switching languages after the first pass returns stored data in milliseconds. In my test, reopening a recipe and changing language made zero translation requests. The model still does the work — just not while you are waiting.

4. Voice and PWA

Cook mode uses ElevenLabs Conversational AI for the live agent, with a browser speech fallback. Sessions are scoped to a recipe and language. The same Scribe integration that rescues silent captions also makes the app work for people who would rather talk than type.

The frontend is vanilla JavaScript, CSS variables, and a service worker. No framework, no build step. The PWA has a share target, an offline shell, light and dark themes, and maskable icons.

5. The boring parts that make it real

Clerk for auth, with every query owner-scoped.
MongoDB Atlas for recipes, stored translations, and agent sessions.
Sentry spans around ingest, extraction, translation, chat, and agent calls.
Docker with Python, ffmpeg, and yt-dlp, plus a render.yaml blueprint.
Tests for the parser, ownership checks, and API behavior.

What broke, and what I changed

Instagram is hostile to scrapers. I stopped pretending one path would work and built the cascade.
Captions lie. Some have no amounts; some have no method. Scribe handles the audio fallback.
Latency is a feature. I removed fake progress and made the status text honest.
Mobile needed to be first-class. Share target, large tap targets, voice, install prompt.
Translations should not be a loading spinner. Precompute them, then get out of the way.

Why Does Open Innovation Matter?

Open innovation matters here because the economics of a small product like this are brutal if every useful action is a markup on a closed API.

Gemma is open-weight. That means:

Model choice is a config line, not a rewrite. If a smaller model gets good enough, I can swap it and cut costs.
A niche product can exist. A tool for home cooks in 10 languages does not need venture scale to be useful. Open weights make the unit economics possible.
Privacy and self-hosting are real options. The Docker image can run with your own keys and your own database. Your recipes are not locked into my account.
The long tail gets served. Regional dishes, regional languages, and weird family recipes are exactly the cases closed models ignore.
The glue is open source too. yt-dlp, ffmpeg, Express, and the PWA platform do a lot of the unglamorous work.

I still use hosted services — ElevenLabs, Atlas, Clerk, Sentry — and I am honest about that. But the intelligence at the center is open-weight and replaceable. That is the difference between building a product and renting one.

My First User

I gave an early build to a close friend who cooks at home almost every day. I’ll keep his name private. He is exactly the person I built this for: saves reels, cooks from his phone, hates reading captions.

He used it on the links he already had saved. Then he asked to keep using it.

Would he pay? He already did. That is the only validation I trust right now.

I am not calling Simmer a startup. It is one paid pilot, a lot of late nights, and a clear next step. That is enough to keep going.

FAQ

What is Simmer?

An open-source AI recipe assistant that turns cooking links, reels, and pasted text into structured recipes, then helps you cook them hands-free.

Does Simmer work with Instagram Reels?

Yes, for public links. Instagram is the messiest source, so Simmer has caption, embed, metadata, and audio fallbacks rather than a single scraper.

Does it work with YouTube Shorts and TikTok?

YouTube is a tested path. TikTok depends on the region and whether yt-dlp can reach it, so it is not the primary path.

How long does it take?

About 1–3 minutes for a public link. Audio transcription can take longer. Translations are prepared in the background, so switching languages is instant after the first pass.

Is it really open source?

Yes. MIT licensed. The repo includes the server, PWA, Dockerfile, and setup docs.

Can I self-host it?

Yes. Run the Docker image with your own Gemma, MongoDB, Clerk, and ElevenLabs keys. The README has the details.

Why 10 languages?

Because recipe videos travel across languages, but the useful instructions usually do not. Translations are stored per recipe, so the app stays fast.

Prize Categories

Best Use of Gemma — Gemma 4 is the extraction, chat, and translation engine. It is open-weight and swappable with an environment variable.
Best Use of Render — Simmer ships as a Docker service with a render.yaml blueprint.
Best Use of ElevenLabs — Scribe for audio fallback, and the conversational agent for hands-free cook mode.
Best Use of MongoDB Atlas — recipes, owner-scoped data, stored translations, and agent sessions.
Best Use of Sentry Agent Tracing — spans around ingest, extraction, translation, chat, and agent calls.

Final thought

Simmer is the first thing I have built that someone paid for before it was finished. That is the side-hustle test I care about.

If you cook from reels, try it on the link that usually defeats you. If it breaks, send it to me. That is the next bug I want.