TutorialsSeptember 1, 202612 min read

How to Build Notetakers That Record Meetings Without Bots

A botless notetaker captures meetings from the user's own machine instead of joining as a participant. This guide walks through the architectures, trade-offs, and how to ship one to production.

Taking notes without bots is becoming increasingly popular. While a bot-based notetaker joins the meeting as a participant and records audio and video from the meeting, a botless notetaker captures the meeting from the user's own machine and does not require a bot to join.

This guide walks through what a botless notetaker actually has to do, what each architecture costs you, and how to ship one to production.

What are the three ways to build a botless notetaker?

ApproachRecord desktop meetingsAuto-start recordingSpeaker namesCross-platformTime to production
Chrome extensionNoNo (user gesture required)NoChromium browser onlyNot suitable for production
Native macOS APIsYesNeed to build yourselfNomacOS only6-12 months
Recall.ai Desktop Recording SDKYesYes, built-inYes, out of the boxmacOS and Windows with one integrationDays

Below is what each option looks like in practice.


Option 1: Creating a Chrome extension

A Chrome extension is a common first idea but is almost always a poor use of time for meeting recording. Building an extension that captures audio and video from the browser isn’t actually that difficult, but the quality will be unsuitable for production.

Here are four concrete reasons why this path is a dead end:

A Chrome extension cannot record native desktop clients. If a user joins from the Zoom app or the Microsoft Teams app — which is how most Zoom and Teams meetings actually happen — you capture nothing. The same applies to meetings joined in Safari and Firefox.

This method requires a user gesture. Chrome’s APIs necessitate that recording cannot start automatically in the background. Someone has to remember to click "Record" at the start of every single meeting. In practice, people forget and important meetings won’t get captured.

Background tabs get throttled. When the user switches away from the meeting tab, Chrome can throttle the tab, which freezes or drops audio and video until they switch back. Telling users not to multitask during meetings is not realistic, but neither is having poor-quality recordings.

You get one mixed audio stream. There is no per-participant separation, so speaker attribution degrades to whatever your diarization model can guess.

Some teams pitch a Chrome extension as an MVP to validate demand. That reasoning fails too: your test users experience a product materially different from what you'd ship, so their feedback isn't actionable, and none of the extension architecture carries over to a production build. This ends up wasting engineers’ time without any learnings to show for it.


Option 2: Building with native macOS APIs

This path is doable, but requires a substantial time investment: around 6 months of work for a team of 5 engineers.

There are 3 macOS APIs suitable for meeting capture, though none of them are sufficient on their own. They do not automatically offer diarized audio or speaker labels, impacting the quality of any notes generated.

ScreenCaptureKit captures screen video, system audio, and (on macOS 15 and later) microphone audio. However, developers must create a fallback for users on older versions of macOS before launching to production, increasing their time to market. In order to create clean recordings, developers also need to build in their own logic to isolate meeting audio from notifications, music, and any other irrelevant audio on the device.

AVFoundation / AVAudioEngine gives you a clean, direct path for microphone capture through the input node. However, it cannot capture system or application audio at all.

Core Audio process taps let you capture outgoing audio from a specific process or process tree. On macOS 14.2 and later, Apple expanded this to cover audio from other applications with user permission, which made per-app meeting audio capture feasible for the first time. One catch is that browser-based meetings distribute audio across multiple processes, so you must identify and track the correct process group for the entire duration of the call – a more difficult task than it seems.

When native APIs are the right call: a narrow feature on a single controlled macOS version, or a product where owning the entire media stack is itself the differentiator. If you are building a notetaker, it is not.


Option 3: Building on Recall.ai's Desktop Recording SDK

If your product's value is the notetaking experience itself rather than the recording infrastructure behind it, we recommend Recall.ai's Desktop Recording SDK. It's the only solution that covers macOS and Windows while handling both browser-based meetings and native desktop apps. The Desktop Recording SDK captures in-person conversations as well as those on Zoom, Google Meet, Microsoft Teams, and more.

Without developers having to do any additional work, the Desktop Recording SDK handles all the edge cases related to meetings, including meeting detection, window tracking, system and microphone audio capture, echo cancellation, stream synchronization, mute detection, microphone switching, resource optimization, real-time durability, and diarized transcripts with speaker names.

Recall.ai supports a variety of transcription providers and modes, including a native transcription service as well as integrations with well-known providers like Deepgram and AssemblyAI. Developers can use real-time transcription to build a botless notetaker that takes live notes, or asynchronous transcription for a notetaker that compiles notes after a meeting ends.

Here’s how it works:

  1. The SDK fires a meeting-detected event when a meeting starts locally.
  2. Your desktop app asks your backend for an upload token.
  3. Your backend calls Recall.ai's Create Desktop SDK Upload endpoint and returns the token.
  4. Your desktop app calls startRecording with the token and the window ID.
  5. Your backend receives the sdk_upload.complete webhook when the upload finishes.
  6. You can run asynchronous transcription (if you want transcripts after the call as opposed to in real-time)
  7. You download the recording and transcript.

By capturing separate audio streams per participant, Recall.ai can generate perfectly diarized transcripts and ensure speech is always attributed to the right person. This ensures that notes – or anything built on top of meeting notes, like tasks assigned to specific people – are accurate. Once you have the transcript, you can pass it to an LLM to generate specific artifacts based on the meeting, such as a summary, action items, a CRM entry, a follow-up email, or a support ticket.

For a more concrete implementation example, there are also sample apps available that show what a basic notetaker built with Recall.ai’s Desktop Recording SDK would look like.

Conclusion

Botless notetaking comes down to a build-versus-buy decision about recording infrastructure. A Chrome extension fails on the basics: it only works on Chromium browsers and can't start on its own. Native macOS APIs can get you there, but you'll be stitching together multiple APIs and creating separate processes for different devices, which takes months of work.

Meanwhile, the Desktop Recording SDK allows you to create a notetaker that works across devices and accounts for all the specific video, audio, and transcription considerations relevant to meetings. Rather than build a subpar solution from scratch, you can use Recall.ai's Desktop Recording SDK to launch a high-quality botless notetaker into production quickly.