I'm building my own meeting manager so every summary knows the client.
In a July 2026 live stream I worked on an open-source tool that turns meeting transcripts into summaries, task lists and recap emails, filed under the client they belong to. It was a build in progress, and I said so.
The business case
I take piles of meeting notes. Then I don't act on them, or I miss something, and at the next meeting I'm scrambling to remember what we agreed. We've all been in the meeting where everyone says "let's do it", and the next week nobody mentions it again.
The tool I used could record a meeting, transcribe it and even build a task list. It had no client context. It couldn't organize anything by client or by person. If you consult, or work with many clients across many projects, that gap costs you follow-through.
So I decided to build a real system, because I need one. I've tried almost every meeting tool. Companies in that space offered to sponsor my channel, and I turned them down because I couldn't be objective about the platforms. I also keep meeting notes outside the AI tools, so I still have them in my own format if I cancel a subscription or switch platforms.
The plan
Read.ai joins my Zoom calls like an ordinary participant and takes the transcript. I keep that part. What I wanted to own is the layer after it.
Read.ai sends a webhook with the transcript. The webhook can land anywhere: Zapier, Make, a Cloudflare Worker, or anywhere else that can catch it. From the transcript I generate three things. My own summary, always in client context. A to-do list, also in client context, with tasks assigned to people in my company. And a recap email to everyone who attended.
The problem with most meeting tools is that each meeting gets recorded in its own isolated system. The AI has no way to say "we worked on this last week." My fix is to pull my internal notes on that client, and what we're trying to achieve with them, into the context before the AI summarizes.
The app and its stack
The interface was already built in an earlier video. Companies and people sit down the left, with a switch between work and personal. Each meeting's summary sits in the middle, and the tasks tied to that conversation sit on the right.
On stream I first called it a Nuxt app, then checked and corrected myself. It's a Next.js app, deployed as a Cloudflare Worker with a D1 database. D1 is SQLite underneath. The tables cover customers, meeting notes and a to-do list. A Wrangler config file ties the app, the Worker and the D1 binding together and applies it on deploy.
The project is fully open source. I'm building it because I need it, not to earn from it. If someone wants to use it or build a company on it, I'm happy for them.
Jump to
- 0:00 Intro: why meeting notes get lost
- 8:37 The plan: Read.ai webhook to client-context summaries, tasks and recaps
- 15:07 A roadmap from your own code, and a tour of the app so far
- 25:18 The stack: Next.js, Cloudflare Workers and D1
- 37:57 Creating the D1 database; Copilot vs Codex vs Claude
- 53:14 Keeping secrets safe in an open-source deploy
- 1:10:30 Tangent: letting Codex run a Facebook ad campaign
- 1:23:32 Deploy result, what Read.ai does well, and wrap-up
I walk through the build on screen in the full video on my channel: Turning meeting transcripts into action items on YouTube.
Secrets in a public repo
The open-source part raised a question I couldn't answer on the spot. If the deploy runs from a public repo, are my Cloudflare tokens exposed? I asked ChatGPT live, and we worked through it.
The Cloudflare API token goes in as a GitHub Actions secret. The D1 database ID in the Wrangler file isn't a secret. Anyone who forks the repo adds their own secrets. Repository secrets live under the repo's Settings, then Secrets and variables, then Actions.
I walked through creating a Cloudflare API token with edit access to Workers and D1, plus read access to account settings so you know what's happening. Then I had Codex build the GitHub Actions workflow and set the secrets through its Cloudflare access. If you're streaming, don't show secrets, and use a private browser window.
Codex came back with a database migration, a private API worker, a frontend deploy order and approval steps. It also turned on Cloudflare Access for production. I told Codex to drop it, since I didn't need a login there.
What Read.ai does well
I use Read.ai and it does a fantastic job. For each meeting it gives me a summary, an action plan and next steps, plus the full recording, a short trailer and the key moments.
What I'm adding is the memory between meetings: summaries and tasks grouped by company or person, in the context of everything we discussed before. That's the core idea of the whole tool.
Where it stood
By the end of the stream it was deployed, but it held only sample data. The webhook wasn't wired up yet. That was the next step, and I planned to show the finished project in my community.
The goal is simple to state. When a client call ends, the promises made in it should turn into tasks with owners, and the next call should start from where the last one left off. For more on the recorder side, see my Read.ai, Fireflies and Otter comparison, and for the same Worker and D1 stack, how I'd build a SaaS on Cloudflare. If your client calls aren't turning into action and you want to map a fix, that's what I cover in a 1:1 strategy call.
About Dwain
I'm Dwain Browne, Founder of LeadScore AI and SnapSuite. I'm a Toronto-based software architect with 25+ years across software, sales, operations and entrepreneurship. SnapSuite helps contractors and trades teams get paid faster, and LeadScore AI shows you which leads deserve your next call. I also run Vibe Code to Profit, a community helping people build software with AI.