A set about designing work well, the products, the meetings, the ideas, and the roles.
Olivier Girardot’s Good Software Knows When to Stop is a quiet but pointed essay about recognizing when a piece of software has found its purpose and should stop expanding to fill every adjacent need. Constraints are advantages. Small teams building focused tools make better decisions than large teams trying to satisfy every feature request. The lessons draw from 37Signals’ early books and apply specifically to the temptation, particularly present when building with AI, to keep adding because adding is now cheap.
Behzod Sirjani’s Meetings Are Products is the best thing I’ve read about meeting design in years. Most meetings are “vibe-coded”, scheduled with good intentions and no design. His four-question framework (who, what, how, when) applies the same discipline to meetings that you’d apply to software. The sentence completion test, “This meeting will be a good use of time if [who] can [what] by [how]”, is now part of how I think about any recurring block on my calendar. The Vercel example, where fixing the “who” in a Monday launch review meeting resolved hours of follow-up Slack, is concrete and instructive.
Josh Pigford’s I Killed a Business Idea in 20 Minutes is a case study in deliberate idea invalidation. He had an idea that depended on AI image generation hitting certain cost and speed thresholds. Instead of building a prototype and discovering later that the economics don’t work, he had Claude write a benchmarking script that tested ten different image generation models across four prompts, measured generation time, and tracked per-image cost. Result: the fastest models produced garbage, the good models were too slow, and the margins didn’t work. Dead in 20 minutes at $2 in API costs. “My brain is constantly running 1000 mph and my default with an idea is to just build it”, I recognize myself in that sentence, which is exactly why I found this useful.
Craig Mod’s Software Bonkers is the piece I’ve sent to more people than anything else this year. He describes building, in five days with Claude Code, a custom accounting system that does exactly what he needs, multi-currency, multi-country, historical FX rates, tax formatting for US and Japan accountants, Quicken replacement for N=1. His framing of “software for N of 1” and “the era of personal tools” resonates deeply. There’s an important proviso in there: he’s a CS-degree holder who loves technology and has been opinionated about software his whole life. The tools amplify capability but still require taste and intent to wield well.
Laurie Voss’s Developer Relations is the clearest definition of DevRel I’ve found, five pillars ranked by importance: documentation first (highest leverage per unit of effort), engineering second (real open source software, not toys), then content and events together, then product feedback, and finally community management. The section on measuring DevRel is where it gets interesting: the honest answer is that it’s unsolved. Dollars, features, attention, and vibe are all real signals but none fully captures it. Sitting DevRel in Marketing or Engineering underweights it in both directions. Worth reading if you work on any developer-facing product.