There is a specific kind of professional tragedy that occurs when you spend 20 minutes typing up meeting notes, only to realize no one opened the document. The effort feels wasted, the context is lost, and the momentum of the project stalls. For a long time, I accepted this as the "tax" of collaboration—until I decided to automate the most boring part of the process using private on-device AI that runs locally in the browser.
We built a simple internal utility called Meeting Minutes. It isn’t a flashy consumer app with a landing page designed by a three-person marketing team. It’s a utility. It’s the digital equivalent of a really good notebook that writes itself.
The issue with traditional meeting notes isn’t just that they are tedious to write; it’s that they are inherently biased. When you take notes, you filter information through your own understanding of the conversation. You decide what’s important. You miss the nuance of a side comment because you’re focused on the main point. And inevitably, you forget to tag the action items or assign owners until it’s too late.
I wanted to remove the human bottleneck from the recording phase, not the analysis phase. The goal wasn’t to replace the meeting; it was to preserve the fidelity of the discussion without the cognitive load of transcription.
The technical decision here was deliberate. We didn’t send audio streams to a cloud server for processing. Instead, we leveraged WebAssembly and modern browser APIs to run the transcription and summarization logic entirely on the user’s device. This means private on-device AI handles the heavy lifting.
Why does this matter for an internal tool? Security and latency. When you’re discussing sensitive roadmap details or personnel changes, sending that audio to a third-party cloud provider introduces a trust gap. By keeping it local, the data never leaves the browser tab. The AI processes the audio stream in real-time, generates a transcript, and then synthesizes a summary with clear action items. It feels instantaneous because the round-trip time to a server is eliminated.
For developers, this is also a fascinating constraint. Building AI features that run in the browser requires a different mindset than building backend services. You have to be mindful of memory usage, battery consumption, and the varying capabilities of client hardware. But the payoff is a user experience that feels native and private, without the complexity of managing API keys or data egress costs. There is a prevailing myth in SaaS that you need viral loops or public-facing organic growth hooks to succeed. This tool doesn’t have those. It’s not designed for Twitter threads or product hunt launches. It’s designed for the quiet, consistent utility that keeps a team functioning.
Internal tools are where the real friction lives. They are the "glue" software. When you build for internal efficiency, you aren’t trying to wow a user with a new feature; you are trying to save them 15 minutes a week. That 15 minutes compounds. Over a year, that’s nearly two weeks of saved time.
We built this because we were tired of the "who said what" game. We wanted a record that was accurate, searchable, and generated before the meeting even ended. It’s a small thing, but it changes the rhythm of the work week. You stop worrying about the administrative overhead and start focusing on the decisions being made.
Building this was a reminder that not every problem needs a massive architecture. Sometimes, the best solution is a focused utility that does one thing well: captures context accurately and privately. It’s not about the AI itself; it’s about how the AI is deployed. By keeping it local, we maintained privacy and speed, two things that are often sacrificed in the name of convenience.
I’m curious to hear from other builders in the community: How do you handle the trade-off between privacy and convenience when integrating AI into your internal workflows? Do you prefer the simplicity of cloud APIs, or are you moving toward local processing?