Adding caching to FolderPress took maybe an hour. Removing it was one of the best decisions I made.

The problem wasn’t the caching itself. It was what caching did to everything else.

#The Tax

Every feature I built afterward had to answer questions that had nothing to do with the feature: Where’s the cache boundary? Which tags need invalidating? Who’s responsible for invalidation — the domain logic or the framework layer? What loading states does this create?

Rename a site? Invalidate the site cache, every post cache under it, the route cache. Edit a post from the Dropbox sync workflow? Different invalidation path than editing from the dashboard. Refactor how pages compose? Audit every caching boundary you’re crossing. Add a new field to the post model? Trace which cached components depend on it.

Caching became a tax on thinking. Not on performance — on development velocity. Every refactor required a mental audit of cache boundaries. Every new feature had a shadow feature: figuring out how it interacts with the cache.

Then the bugs: stale data after edits, invalidation timing that was hard to reproduce. The kind of bugs where the fix is “wait a few seconds and refresh” — which means you don’t actually understand the problem.

#The Step Back

The database handles a few requests per second without breaking a sweat. Pages render in under 200ms without caching. There’s no bill to optimize. There’s no load to protect against.

I was paying a complexity tax for a performance problem that didn’t exist.

#The Decision

Remove caching entirely. Every page hits the database. Every render is fresh. The code got simpler. The bugs disappeared. Features got easier to build because every change stopped requiring a cache audit.

When the component composition is stable — when I’ve stopped rearranging how pages are built — I’ll add caching back. By then I’ll know which data is actually expensive, which pages are actually slow, and which boundaries actually make sense. Real problems with real data instead of imagined problems with imagined load.

#The Pre-PMF Lesson

Before product-market fit, every hour spent on infrastructure is an hour not spent learning what users want. “Fast enough” is the right bar when you have zero users and a hundred questions about what the product should be.

Caching is the right solution — later. Moving fast is the right solution now. And moving fast means less code, not more.