Why we built MangoFinch as a browser app, not a desktop app

Early in development, we had to answer a question that shapes everything downstream: does MangoFinch live in the browser or on the desktop?

We chose the browser. Not because it was easy. In some ways it was harder. But eight months in, I am confident it was the right call, and I want to walk through the reasoning because the tradeoffs are not obvious.

The IT department problem

Before we talk about technology, let us talk about procurement.

Getting a desktop app approved at a 500-person company takes, on average, 6-8 weeks. I know this because three of our beta testers told us their exact timelines. One company in Frankfurt took 11 weeks to approve a macOS installer because their security team required a manual code audit before anything touched employee machines.

A browser app requires zero approvals at most organizations. The user opens a URL. That is it. No IT ticket, no installer review, no admin privileges, no MDM policy update.

We watched a competing product lose a 200-seat deal because the procurement cycle exceeded the buyer's budget window. The team wanted the tool in Q3. The installer got approved in Q4. By then the budget was reallocated. A URL would have closed that deal in a day.

This alone almost decided it. But the technical arguments mattered too.

Cross-platform by default

MangoFinch runs on Windows, macOS, Linux, and ChromeOS. We did not write a single line of platform-specific code to make that happen. Chrome is Chrome. Firefox is Firefox. The Web Audio API behaves the same on a Chromebook as it does on a MacBook Pro.

A desktop app would mean four build targets. Four sets of platform bugs. Four update pipelines. We are a small team. Maintaining four native builds would consume roughly 30% of our engineering bandwidth based on what I have seen at previous companies that tried this.

The math is specific. Each platform has its own audio subsystem. macOS uses Core Audio, Windows uses WASAPI, Linux uses PulseAudio or PipeWire depending on the distro. Each one handles sample rates, buffer sizes, and device enumeration differently. A desktop app needs an abstraction layer over all three, and that abstraction layer needs testing on every OS update. Apple ships macOS updates roughly every 6 weeks. Windows pushes cumulative updates monthly. Any of those can change audio behavior and break an app that talks directly to the OS.

In the browser, we call navigator.mediaDevices.getUserMedia() and the browser handles the abstraction. If macOS changes its audio subsystem, that is Google's problem (Chrome) or Mozilla's problem (Firefox), not ours. We have engineers, and I would rather they work on improving translation latency than chasing a PulseAudio regression on Ubuntu 24.04.

ChromeOS matters more than people think. Schools and budget-conscious organizations run millions of Chromebooks. Google shipped 33 million Chromebooks in 2025. A native app cannot reach them at all. A browser app reaches them for free. One of our earliest beta users was a bilingual school in the Netherlands running Chromebooks across every classroom. They could not have used a desktop-only product.

WebRTC is mature enough

Three years ago, I would not have made this choice. Browser audio APIs were inconsistent, WebRTC had painful edge cases across browsers, and the getUserMedia permission model was confusing for users.

That has changed. WebRTC is now stable across every major browser. The MediaStream API gives us consistent access to microphone input. We get real-time audio at 16kHz or higher, which is what our speech engine needs for accurate transcription.

Our audio pipeline in the browser looks like this: getUserMedia captures the mic, a MediaRecorder encodes the stream, and a WebSocket sends chunks to our server. Server-side, we forward to our speech engine, receive transcriptions, run translations through our translation layer, and push results back through the same WebSocket. Total round trip: about 1.4 seconds median.

That 1.4 seconds would not be meaningfully faster in a desktop app. The bottleneck is the speech processing and translation steps, not the browser. We measured: replacing the browser's WebSocket with a native TCP socket saves about 8ms. That is noise compared to the time spent on external API calls.

We also tested the Web Audio API's AudioWorklet for real-time audio processing. It runs in a dedicated thread, separate from the main UI thread, so the interface stays responsive even during heavy audio processing. Three years ago, AudioWorklet support was spotty. Now it is available in every browser we target, and the performance is within 5% of native audio processing for our use case.

What we gave up

I want to be honest about the real downsides, because there are two significant ones.

**System audio capture is harder.** In a desktop app, you can hook into the operating system's audio output and capture what other participants are saying through the speakers. In a browser, you cannot do this directly. The browser sandbox prevents access to system audio for good security reasons.

Our workaround: we use the Screen Capture API with getDisplayMedia. When a user shares their screen (or a specific tab), we get the audio track from that share. This works, but it requires an extra permission click. The user has to select "Share tab audio" or "Share system audio" in the browser's screen-sharing dialog.

Is this worse than a desktop app? Yes, by one click. In practice, 89% of our users complete this step on their first try. We added an animated guide that shows exactly which checkbox to click, and the drop-off rate went from 22% to 11%.

**No background recording.** A desktop app can run in the system tray and record every meeting automatically. A browser tab has to be open and visible. If the user closes the tab, the transcription stops.

We mitigate this with browser notifications. If a meeting is active and the user navigates away, we fire a notification reminding them to keep the tab open. We also use the Page Visibility API to warn when the tab is backgrounded, since some browsers throttle background tabs after 5 minutes.

These are real limitations. For users who need always-on recording across every app, a desktop solution like Otter or Krisp is a better fit. We are not trying to be that product.

Why Electron lost

We considered Electron seriously. It would give us a desktop app built with web technologies. Same JavaScript codebase, native-feeling window, access to system audio, background operation. On paper, it solves both downsides.

In practice, Electron introduces three problems we did not want.

**Update distribution.** Every Electron app needs its own update mechanism. Auto-updaters break on corporate networks with proxy servers. We talked to two teams running Electron apps in enterprise environments, and both reported that 15-20% of their user base ran outdated versions at any given time because updates failed silently behind firewalls.

A browser app updates instantly. We deploy, and every user gets the new version on their next page load. Zero percent running outdated code. Zero update tickets.

**Memory footprint.** Electron bundles Chromium. Each Electron app is its own browser instance consuming 200-400MB of RAM at baseline. Our users are in meetings. They already have Zoom or Teams open, a browser with 15 tabs, Slack, and their email client. Adding another 300MB process for transcription is hostile to the user's machine.

MangoFinch in a browser tab uses about 80MB. It shares the browser process the user already has running.

**Security surface.** Every Electron app ships its own copy of Chromium, which means every Electron app is responsible for patching Chromium vulnerabilities independently. The average time from a Chromium CVE to an Electron patch across popular apps is 14 days based on a 2025 audit by Trail of Bits. That is 14 days where known vulnerabilities sit on users' machines.

In a browser, Chrome auto-updates within 24-48 hours of a security patch. We inherit that protection for free.

Our PWA roadmap

The browser is our primary delivery mechanism, but we are building Progressive Web App capabilities on top of it.

**Offline transcript viewing.** This ships in Q3 2026. Service workers will cache completed transcripts locally, so users can review meeting notes without an internet connection. The transcripts sync back when connectivity returns. We are targeting storage of up to 500 transcripts per device using IndexedDB.

**Push notifications for meeting summaries.** When a meeting ends, MangoFinch generates a summary (key topics, action items, decisions). We will push that summary as a browser notification 2 minutes after the meeting closes, so it arrives while context is fresh. This uses the Push API and requires the user to grant notification permission once.

**Install to home screen.** PWA install prompts will let users add MangoFinch to their dock or taskbar. It opens in its own window, without browser chrome, and feels like a native app. Combined with offline viewing, this closes most of the gap between a browser app and a desktop app without any of the Electron overhead.

**Persistent room links.** We are building the ability to save room configurations so users can rejoin recurring meetings with one click from their installed PWA. Your Monday standup, your Wednesday cross-team sync, your Friday retro — each gets a persistent link that remembers your language preferences and participant list. Open the PWA, tap the room, and you are live in under 3 seconds.

The PWA approach also lets us iterate faster on mobile. On phones, the installed PWA behaves like a native app, and we did not have to submit anything to the App Store or Google Play. No 2-week review cycles, no platform-specific guidelines about what we can and cannot do with audio. When we fix a bug, phone users get it at the same time as desktop users.

The numbers so far

Since launching the beta, we have onboarded 340 teams across 12 countries. Zero of them had to file an IT request to start using MangoFinch. The median time from first visit to first transcription is 3 minutes and 40 seconds. That includes account creation, mic permission, and starting a room.

For comparison, a desktop transcription tool we benchmarked against had a median time-to-first-transcription of 22 minutes, mostly because of download time, installation, and the "allow this app" security prompt on macOS. Windows was slightly faster at 18 minutes, but the Defender SmartScreen warning ("Windows protected your PC") caused 30% of test users to abandon the installation entirely.

I do not think the browser is always the right answer for every product. Video editing needs native performance. 3D rendering needs GPU access that browsers still gate awkwardly. But for real-time audio capture, transcription, and text rendering, the browser is fast enough, secure enough, and dramatically more accessible.

We chose reach over control. For a product whose entire point is to include every person in the meeting regardless of their language, that felt like the right principle to build on.