Why we built Smol

A podcast episode leaves you with recordings, an edit, thumbnails—and a conversation about all of them. We’re building Smol so the next person can pick up that work in one place.

It’s like Slack and Google Drive had a baby: a team drive with a conversation in every folder. Smol brings together our existing work on a chat app and a document drive. The podcast handoff has been testing that combination ever since.

The handoff we’re optimizing for: open the project and recover its context. This is a workflow illustration, not a measured reduction in app switching.

Eight files made the problem concrete

One real handoff arrived as a ZIP: a large MOV recording, a WAV, and six thumbnails. The thumbnails could finish extracting long before the recording. People needed to use them while the import continued.

That gave us a practical requirement: rename a completed thumbnail, move it, start reviewing it—and let the recording keep arriving. A folder should show what is ready, what is processing, and what needs attention.

Put the discussion beside the files

“Who is reviewing the edit?” belongs with the project. “This passage needs a correction” belongs on the file. Smol gives each a home: ongoing folder chat, and comments attached to passages and versions.

Local Smol build with synthetic demo content: messages on the left, files on the right, and channel/status columns in the sidebar. Click either screenshot to view it full size.

When a new cut arrives, an earlier comment still opens the version its reviewer saw. An owner and status help the next person find who has the work and where it stands.

Local build with synthetic content: a passage, its comment, and the version it refers to stay together.

Find the quote, then check the source

Later, someone needs a quote for the introduction. Smol turns supported audio and video into transcripts, and extracts text or OCR from documents so workspace search can reach beyond filenames.

A 102-second synthetic WAV in our browser check reached a ready transcript and completed indexing. That verifies the path; we haven’t measured processing latency. “Ask this file” can answer about a selected version with source citations. Workspace-wide assistants and agents are future work.

If transcription fails, the original stays available. Processing should add something useful without blocking access to the file.

Keep the progress when the connection drops

We tested a 200 MiB upload, reloading after 18 of its 20 parts had been acknowledged. After reselecting the original, Smol sent only the last two parts.

20 MiB sent after resume. About 3 seconds from the resume check to commit. The downloaded file’s hash matched the original. Bytes wasted by an in-flight request before reload weren’t measured. The full-restart bar is a calculated baseline, not a claim that Google Drive or Dropbox always restart.

Raw speed still needs work. Here are both observations from our first small comparison:

Payload start through commit; two trials per service on one Mac/network, October 5, 2026. Picker time excluded. Account types differed, background traffic wasn’t controlled, and repeated identical bytes may benefit from caching or deduplication. This is a small baseline, not a general ranking. Raw measurements.

Start with one project

Google Drive and Dropbox already store files; Slack already hosts conversation. Our bet is that putting the originals, feedback, references, and next step in the same folder makes a handoff easier to pick up.

We plan to pass through cloud storage and transfer costs without markup. Billing is planned; processing has separate costs.

Smol is alpha: data may be lost, operators may read stored data, and you should keep backups. Files are unlisted public by default—anyone with a file’s link can access it. Change sharing policies for private work.

Open Smol or get the Mac beta. Start with one project whose files and conversation you currently have to piece together.