I opened Google Drive on a Tuesday afternoon looking for one file. I found everything.
799 files sitting in the root folder. Thirteen years of daily output with no taxonomy, no system, no filing logic. Just the accumulated evidence of creating fast and never pausing to organize what I'd built.
Here's the inventory of what was actually there: sales enablement frameworks built for corporate clients, draft chapters from 17 books (6 published while I held a senior enablement role full-time), app audit logs from the early builds of what became Autonomous Revenue Labs, consulting invoices going back to 2013, cover letters from career transitions, AI training decks I built for internal sessions, and daily writing sessions that didn't become anything.
All of it, flat. One folder. One pile.
The cleanup
The manual sort took two hours. I created a folder structure that matched how I actually work now, not how I assumed I'd work in 2013, and moved everything to its correct location.
The more interesting decision was what I built after.
The real problem with 799 files in root isn't disorganization. It's that I'd built no system for routing output as it was created. The pile is the result of a decade of creating fast, publishing consistently, and treating filing as a problem to solve later.
The solution to "later" is automation.
What I built
I already run a content engine that publishes across 40+ platforms from a Supabase pipeline. The marketing_queue table routes content to Comet, which handles distribution to Mastodon, Pinterest, Medium, Substack, and the rest. The same logic scales to file routing.
For the Drive problem: a classification script (Python, about 120 lines) that reads file names and modification dates, infers content type (enablement doc, book draft, app log, personal writing), and moves to the correct Drive folder. A weekly cron job that checks root for files older than 7 days and routes them. A Supabase log table (file_routing_log) that records every move for audit.
Build time: 3 hours. It will run indefinitely.
Failure modes I hit during testing: files with no modification metadata got routed to a catch-all folder instead of classified correctly. Files with ambiguous names ("notes.doc", "draft.txt") required a content-inspection fallback. Google Workspace files don't have the same metadata structure as uploaded files, so they needed a separate handler.
Current state: handles about 90% of cases automatically. The remaining 10% goes to a review queue in Supabase for manual routing once a week.
The actual lesson
799 files was proof of output. The pile accumulated because I was creating. The problem was the capture layer, not the creation rate.
Most productivity advice targets creation habits. Write every day. Ship consistently. Build in public. All correct. What breaks down at scale isn't the creating. It's the organizing.
The system you build to handle your output after you create it is as important as the habits that produce the output in the first place.
I built ContentForge for the same reason. Reformatting content across 8 platforms was eating the time I should have been using to create more. The solution was automating the reformatting.
Build the system. Create faster. Let the system handle the pile.
What I'd do differently
Build the routing layer on day one of any creative system. Every time. The cleanup cost two hours. Building the router after the fact cost three. Building it at the start would have cost thirty minutes.
The pile is a symptom of the right problem: high output. The fix is infrastructure.
What's next
The content-inspection fallback needs improvement. Currently doing simple keyword matching on file content for ambiguous files. Moving to a lightweight classifier trained on my actual content types. If I get classification accuracy above 95%, I'll open-source the script.
If you're sitting on a similar pile: the root cause is almost always the same. You've been creating. You just need infrastructure to handle what you've built.
Top comments (0)