Blog

The case for local-first screen recording

The case for local-first screen recording
Why "cloud-based screen recorder" means your footage leaves your machine before you've shared it with anyone — and what local-first actually requires.

Every time you record a Loom of an unreleased feature, the video uploads to a server you don't own, encoded by software you can't audit, indexed for search by a team you've never met. Sometimes that's fine. Often it isn't, and you didn't think about it.

What "cloud-based screen recorder" really means

Most modern recorders are some flavour of cloud-first. The local capture is local — for a few seconds — and then the file is uploaded to the vendor's storage. The vendor:

  • Transcodes the video to multiple qualities for streaming.
  • Runs transcription (often via a third party — Rev, AssemblyAI, sometimes OpenAI).
  • Indexes the transcript for search inside their UI.
  • Generates thumbnails and previews.
  • Logs viewer behaviour, sometimes per-second.

None of this is malicious. It's how the product works. It's also a list of things that happen to the inside of your screen recording without you thinking about it.

What you actually upload

You upload the artefact your screen had on it at recording time. For a marketing video, that's a polished product. For an internal "look at what I just hacked together" video, that's:

  • Your unreleased feature, named.
  • The internal Linear/Jira ticket on your second monitor.
  • The Slack notification that popped up because you forgot to enable Do Not Disturb.
  • Your customer's email in a tab.
  • Your dev console with API keys briefly visible.

You can blur this in post. Most people don't. The footage is already up.

"The footage is already up — before you'd shared it with anyone, before you'd decided what to do with it."

When this matters

It matters when the recording is:

  • Internal — async standups, code walkthroughs, "I'm stuck, here's what I'm seeing" debugging clips.
  • Pre-announcement — anything related to a feature you haven't shipped, a partnership you haven't disclosed, a redesign you haven't launched.
  • Confidential by contract — anything covered by a customer NDA, anything in a regulated industry, anything that touches healthcare or finance data.
  • About third parties — recording a screen that includes someone else's name, logo, dashboard, or output.

For all of these, "local-first" isn't a privacy preference. It's the only acceptable default.

What local-first actually requires

Three properties, in increasing order of how hard they are to get right:

  1. The recording lives on disk. No upload step, no cloud backup of the raw file. Easy.
  2. The transcription runs locally — at least for the languages you record in. Apple's Speech framework ships on-device support for English plus a growing list of major languages; for those it never leaves the Mac. For languages outside that list, Apple's framework falls back to a server request — worth knowing if you record in less common languages. More on this here.
  3. The application makes no outbound calls except for the ones you'd expect. A licence check is fine. A telemetry pipe sending screenshots of your editor is not.

You'd think (3) is paranoid. It isn't — it's a useful exercise to open Little Snitch or Lulu and see which screen recorders phone home and how often.

The speed dividend

There's a non-privacy reason local-first is back: it's faster. A 4K, 5-minute recording is a 1–3 GB file. Uploading that to a cloud over a typical home connection is 2–10 minutes. Trimming on-server then re-rendering is another minute. The local-first version of the same workflow is "trim, click export, done". On an M-series Mac with a real-time editor, "done" is 30 seconds.

~30 s

local trim-and-export on an M-series Mac vs. 2–10 min cloud upload + re-render for the same 4K, 5-minute file

For one video that doesn't matter. For someone making a video every workday, it's an extra hour a week.

What you give up

You give up the share-by-URL convenience Loom is famous for. The cloud-first recorders give you a URL the second you stop recording; the local-first ones give you a file. You can drop the file into Slack, Google Drive, YouTube, anywhere — but it's an extra step.

You also give up the team-level features: comment threads on the timeline, viewer analytics, shared workspaces. If you genuinely use those, a cloud-first recorder is the right tool. If you're recording for an audience that watches the video and never interacts with it through the recorder's UI, the team features are dead weight.

For solo creators, indie devs, founders, and anyone whose screen ever shows internal work — local-first should be the default. CursorFlow is built on that premise; here's why I bothered.

Frequently asked questions

Is Loom a GDPR risk for internal recordings?
It depends on what's in the recording and Loom's data-processing terms. If the video includes a customer's name, a patient record, or financial data, you should confirm Loom's processing terms and EU residency options cover that data. On-device recording avoids the question entirely.
Does "local-first" mean no sharing at all?
No. Local-first means the raw file lives on your disk. You can still share it — drop it into Slack, Google Drive, YouTube, or any CMS. The difference is you control that step; the recorder doesn't do it automatically.
How do I know if my recorder makes outbound calls?
Open Little Snitch or Lulu (both free) and watch the network monitor while you record. Any connection that isn't a licence check or a sharing step you triggered is worth investigating.