I’ve started a blog four times. Different years, different tools, same outcome: a configured website with zero posts.

Each time I’d spend a weekend choosing between Hugo and Jekyll, configuring a build pipeline, browsing themes, tweaking CSS. It felt like progress — effort in, visible result out. But the blog had no words in it. Just infrastructure. The setup wasn’t a stepping stone to writing. It was a substitute for it — productive enough to feel virtuous, safe enough to avoid the blank page.

So I tried the other path. Posted a couple of things on Medium, skipped all the setup. Then work got busy and I stopped. When I came back, the platform had changed under me. Posts behind a paywall I didn’t choose. A different editor. The audience — what little existed — was theirs. The content was technically mine, but locked in a format designed to make leaving expensive.

I hadn’t lost much writing. I’d lost the option to come back on my own terms. That’s the thing about platforms — it doesn’t matter how much you wrote. What matters is that the ground shifts and you don’t control any of it.

Two failure modes. Self-host and you drown in setup, never write. Use a platform and you write on borrowed land. One kills the writing. The other kills the ownership.

I wanted the third option.

#The Setup That Already Worked

I write in iA Writer on my Mac and phone. Everything syncs through Dropbox — notes, drafts, half-formed ideas. Start on the subway, finish on the laptop.

I tried iCloud twice. Lost notes both times. Apple support from two different countries couldn’t recover them. I don’t use iCloud for anything I care about anymore.

So the editor was solved. The sync was solved. Years of workflow, already in place. The only missing piece was the last mile: a markdown file in my Dropbox becoming a page at a URL I control.

That last mile shouldn’t require a CMS. It shouldn’t require a dashboard, a paste-and-reformat ritual, or a publish button. Everything needed to render a blog post — the content, the structure, the metadata — was already in the file. The gap between “I saved this” and “someone can read this” should be zero.

#This Week, It Is

Save a markdown file to Apps/FolderPress/ in Dropbox. It’s a page on your site — clean URL, proper typography, meta tags, RSS entry. Edit the file, the page updates. Rename it, the URL changes. Add .draft to the filename, it’s unpublished.

The folder is the CMS. The editor is the interface. Nothing in between.

Making that work against Dropbox’s API was the hard part.

#The Engineering

Dropbox doesn’t have rename events. A rename produces two events: “file deleted at old path” and “file created at new path.” Process them sequentially and the post disappears before it reappears. In that window, your readers see a 404.

Two-phase processing fixes the common case. Batch all events, process folder-level changes first, file-level second. By the time we evaluate individual files, we already know whether a “deletion” is the first half of a rename.

The harder case: the delete and create arrive in different webhook batches. Dropbox doesn’t guarantee atomicity. FolderPress delays deletions by a grace period, then verifies against the API — does this file exist at a different path? If yes, rename. If 404, real delete. The grace period adds latency to genuine deletes, but the alternative is posts vanishing during renames.

Content deduplication. Every webhook would naively re-download and re-parse every file. Dropbox provides two primitives that prevent this: a content hash per file, and a stable fileId that survives renames. Check the hash — same content, skip the download. Track the fileId — renaming draft-v2.md to final.md is a path change, not a content change.

Scoped access. FolderPress uses Dropbox’s App Folder permission. It can see Apps/FolderPress/ and nothing else. Not a policy — a capability boundary. Full Dropbox access would’ve been simpler to build, but privacy by architecture beats privacy by promise.

None of this is visible from the outside. A writer renamed a file and the URL updated. That’s what should happen.

#Why This, Why Now

This is a narrow tool. Markdown writers who use Dropbox and want a blog without a CMS — that’s a small intersection. But it’s mine, and nothing else serves it.

Git-based publishing requires git. CMS platforms require their editor. Medium and Substack let you write but the content and audience live on their terms, subject to their decisions. FolderPress needs a folder you already have. The files are yours — same markdown before FolderPress, same markdown after. No hostages.

I’m not sure this is a business. I’m sure it’s the product I wanted to exist.