I’m finally publishing my side projects for 2025 on Github — 36,408 lines of code, almost entirely vibe coded.
- Quill, a beautiful, fast, native Mac WordPress blogging editor inspired by IA Writer but with full, bidirectional Gutenberg block support
- Gymtxt, a lightweight way to log workouts as plaintext
- Day One Publish, a way to generate static sites from a Day One journal to share with friends and family
- Shrinksearch, a fast way to search and browse Psychology Today profiles
Some notes from building this year:
- I’ve been preferring one-page tools that read/write from a local CSV, JSON file, or sqlite db — the data layer is easy for the models to use, version controlled, and super fast on the frontend for the user.
- I like UX where the app is a layer on top of plaintext. Gymtxt was my first attempt at this, and I love this travel app with a similar vibe. Treating the text area as the database means the user, LLM, and developer can all easily interact with the same dataset.
- I highly recommend Coolify or Dokploy for vibecoding projects with Claude Code. They’re essentially a self-hosted Replit or V0 — you get a unique URL per project, and they auto-deploy when you push to Github. Set it up once on a cheap $5 VPS and you can go from a new folder on your computer to a link you can share in ~3 steps (create the repo in Github, push to it, and then tell Coolify about the new repo.)
- I’m interested in what LLMs can “see” when processing images. Web projects were easier than native apps because Claude Code could snapshot the page and verify its results vs. native apps where I would largely do that (though I imagine giving screen access in the future will fix that.) But even when snapshotting, specific layout tweaks were sometimes hard for it to see in the generated image.
- Apple should have an App Store submission MCP and an improved notarization experience. The hardest part of Quill was getting it into executable form so people could download it and run directly. Until then, my default stack will skew towards web technologies unless there’s a specific reason to build natively.
- I find it crazy that, when facing a bug the LLM can’t solve, starting entirely from scratch and referencing the old project code will often result in 100% feature parity with the issue resolved. I wonder if coding agents will adopt this as a way to get around roadblocks.
Leave a Reply