Six Weeks of Building in Public: What Actually Happened
I started publishing everything I built six weeks ago. Eight repositories, zero marketing budget, one unexpected outcome: writing about the work changed how I do the work.
Six weeks ago I decided to stop building in private. Every project I started would have a public repo, a blog post, and a real changelog. No waiting until it was "ready." No polishing until it was presentable. Ship the rough version and write about it honestly.
Six weeks later: 8 active repositories and one insight I didn't expect going in.
ShieldX — prompt injection defense for LLMs. Started as a personal tool to protect a chatbot I was running. Grew into a general-purpose framework with 500+ detection patterns, kill chain mapping, and a self-learning system that updates its own rules.
ShieldY — infrastructure security platform. Consolidates five separate security daemons I was running on my server into one Fastify service. 13 detection layers, deception system, BGP blackhole integration.
PeerCortex — BGP/RPKI health check platform. 70,000+ ASNs, 13 health checks, ASPA verification. Built because the tool I needed didn't exist. Got linked in a NANOG thread three days after launch.
Claude-Cortex, Claude-Sync, PaperCortex, Slop-Radar, Claude-Code-Hardened — smaller tools solving specific problems. Each took 2–5 days to build and another day to document.
Writing about the work changed how I do the work. This was not the goal. The goal was accountability and visibility. The outcome was that I started making different architectural decisions because I knew I'd have to explain them.
Specifically: I stopped taking shortcuts that are hard to explain in a blog post. When I couldn't write a clear paragraph about why I chose a particular approach, that was a signal the approach needed more thought — not "I need better words," but "this decision doesn't have a clean rationale yet." The writing became a design review I couldn't skip.
The 2 community-found bugs are the most valuable data point. In private development those would have shipped to production. Public development found them during early adoption when the fix cost is low.
LinkedIn got less engagement than technical forums. A NANOG mention drove more GitHub traffic than two weeks of social media posts. Audience matters more than channel.
Documenting everything takes as long as building it. For tools I'm actively maintaining, the writing investment pays back in community trust and bug reports. For smaller utilities that I've shelved, the ratio was worse.
The publishing cadence is now built into the workflow rather than layered on top of it. The question I ask at the end of every build session: "What would I write about this today?" If the answer is nothing interesting, that's information about the work itself.