Why I Made Loom Archiver Free
I had a personal need, built a real tool, then did the work to see if it was a business. The honest answer was no — so I made it open source.

Most of my writing here starts with a decision, not a line of code. This one is no different.
I built a command-line tool called Loom Archiver. It bulk-downloads your own Loom videos and their transcripts to local storage, preserving your folder structure — including nested folders. It authenticates as you through a real OAuth flow, enumerates your whole library, and writes MP4s and transcripts to a destination you choose. It's resumable, and it guards against filling your disk. I built it because I had a real need, ran it against a library of roughly 1,600 videos, and it did the job.
The code is on GitHub: WillDent/loom-archiver. Python 3.11+, MIT-licensed, 136 tests, CI on Python 3.11 through 3.13. If you want the tool, that link is the point of this post. Everything below is the part I actually want to write about — the decision behind it.

The gap that made it exist
Loom is a lovely product for capturing a thought and sending it to a colleague. It is not a product built for people who want their own library back. There is no bulk export at any tier. There is no button that says "give me my videos." Individual downloads exist, but at any real scale they stop being a workflow and become a chore.
That's the entire reason the tool exists. Your library is portable in principle — the videos are yours, the transcripts are yours — but there is no mechanism to move them in bulk. I wrote the mechanism.
Then I did the harder part
Once the tool worked, I did what I'd tell anyone else on my team to do: I stopped and asked whether this should be a business. Not "could I charge for it" — anyone can put a price on anything — but whether there was a real wedge here.
Two things came back clearly.
The demand that exists is for the wrong shape. People search for how to download a Loom video. Singular. And the top modifier attached to that search is "free." Bulk export — the actual thing my tool does — has effectively no search demand. That is not a market waiting for a product. That is a handful of people, like me, who happen to hit a wall on a Tuesday and want it gone by Wednesday.
There is no forcing function. Atlassian, which owns Loom, preserves your videos when you downgrade your plan. Nobody is staring down a deadline where their content is about to disappear. Without urgency, a paid product has to be dramatically better than "I'll get to it later," and a CLI archiver isn't that.
Put those together and the honest read is: a paid product here has no wedge. It solves a real problem for a small number of people who feel it acutely and infrequently, at a moment when they are least willing to open their wallet.
Free was the honest answer
So I made it free and open source. Not as a marketing move, not as a loss leader for something else — as the accurate response to what the research actually said. If the market isn't there, charging for it doesn't make it there; it just adds friction for the people who need it.
MIT license, tests, CI, a README that tells you the truth about what it does and doesn't do. If it saves someone an afternoon, that is the entire return I'm looking for.
The part I want to keep
The lesson I take from this isn't about Loom, or CLIs, or open source. It's that "should this be a business" is a different question from "can I build this," and the discipline is answering the first one honestly even when you've already done the work on the second. Sunk cost is quiet and persuasive. Research is louder if you let it be.
I needed the tool. I built the tool. I looked at the market and it told me the truth. That's the whole story — and, I think, the useful one.
If you want the tool itself, it's here: github.com/WillDent/loom-archiver.
Subscribe
Get the next one in your inbox.
Roughly monthly. No tracking, easy unsubscribe.
Related reading
How I Got Into Software Development
From building an eCommerce solution by hand at Gulfstream Aerospace to founding a software company — a quick tour of how I learned the craft.
From Read-Only to Responsible Action: Rebuilding the Pipedrive CRM MCP Server for 2.x
Version 2.x rebuilds the Pipedrive CRM MCP Server around modern APIs, safer remote access, predictable responses, and a deliberately constrained path from read-only analysis to controlled action.
The Most Useful AI Work Starts Before the Model
Before AI could prioritize aviation prospects, we had to connect the market data, resolve the identities, and make the operating model trustworthy.