· Brittany Ellich · illustration · 1 min read
Detail of commit message vs. time working on the issue

Beginning of change: “Adding new feature”
End of change: “Plllllllzz work this time”
· Brittany Ellich · illustration · 1 min read

Beginning of change: “Adding new feature”
End of change: “Plllllllzz work this time”
I wanted to add book clubs to my GoodReads-like app (Collective), but ATProto doesn't have a standard way to handle shared group resources yet. So I'm building opensocial.community—a separate service that manages groups independently from any single app. This means the same book club could potentially work across multiple apps (imagine your book club having both a reading list in Collective AND a discussion forum in another app), and groups can migrate between providers if needed. It's probably over-engineered for my use case, but might help other ATProto developers building community features.
For most of my career, I've been confusing building products with building businesses—and that confusion kept me from pursuing a lot of ideas. Two weeks off helped me realize that not everything needs to be a startup, and some of the best things we build are the ones we build just because we want them to exist.
I've cracked the code on breaking the eternal cycle - features win, tech debt piles up, codebase becomes 'legacy', and an eventual rewrite. Using coding agents at GitHub, I now merge multiple tech debt PRs weekly while still delivering features. Tickets open for months get closed. 'Too hard to change' code actually improves. This is the story of the workflow.