How I Decide What to Build vs. What to Fork
The thing that breaks first when you build in public isn't the code. It's your own instinct to just start typing. The moment other people can see what you ship, the cost of building something that already exists stops being a private embarrassment and becomes a visible one. That changes how I decide what to build versus what to evaluate first.
The habit: eval before you build
My own agents have picked this up directly. When Freddy, the agent who runs my Meta Ads work, ran across an open-source repo called "Open Generative AI," he didn't start reimplementing it. He laid out the actual decision in front of me:
- Clone it and evaluate it locally, to see if the Workflow Studio inside it was worth lifting
- Wire it in as the creative engine for the ads-intel dashboard
- Bookmark it for later and move on
That's not a stalling tactic, it's the correct order of operations. The repo got pulled and reviewed, 494.3KB from github.com/Anil-matcha/Open-Generative-AI, before anyone wrote a line of new code against the problem it solves. Building in public means someone can ask "why didn't you just use the thing that already does this," and if the honest answer is "I didn't check," that's the failure mode. If the answer is "I checked, here's what I evaluated and why I passed," that's a defensible decision, and it's the one I want my agents making by default.
What actually breaks: duplicate work at scale
At small scale, rebuilding something that already exists costs you a weekend. At the scale I run at, it costs a lot more, because the surface area to duplicate against is enormous. My own running registry puts the literal count at 1,498 GitHub repos, 1,082 skills, 219 tools, and a Master Brain sitting around 850,000 vectors. The standing rule attached to that registry is blunt about why it exists: building something that already exists is the number one failure mode in this workspace.
That registry isn't a status report I write for show. It's the thing that has to get checked, every time, before a new build starts, because at this scale the odds that something close enough already exists are high. Skipping that check is what breaks under public scrutiny fastest. You can't hide a rebuilt wheel when the registry showing you already had one is sitting right there, dated, in the same repo.
The part you don't control: people are already watching
Building in public also means other people narrate your stack before you get around to narrating it yourself. A creator named Julian Goldie SEO put out a video titled "Hermes Agent + OpenClaw + Aion UI is INSANE!" covering my agent-runtime setup, published back in May. I didn't script that coverage, didn't ask for it, and don't control what gets emphasized in it. That's the actual risk profile of shipping openly: once the dashboards are live and the registry is public-shaped, someone else can pick up the thread and run commentary on it whether you're ready for that or not.
That's not a reason to build more quietly. It's a reason to make sure the thing being covered can hold up when someone else is looking at it cold, with no context you'd normally supply in a demo. If a third party can watch a video of your setup and it still makes sense, the build was solid. If it only made sense with your narration attached, that's a gap worth closing before the next thing you ship.
Where the discipline actually lives
Put those three things together and the pattern is simple. Before building, check the registry. Before building on top of someone else's open-source work, clone it and evaluate it honestly instead of skimming the README and moving on. After shipping, expect that someone outside your team will describe what you built in their own words, and let that possibility shape how cleanly you document and structure things now rather than later.
None of this slows me down in the way people assume "process" always does. It's closer to the opposite. Checking the registry first is faster than debugging a duplicate build six weeks in. Evaluating an open-source repo for thirty minutes is faster than reimplementing it badly and fixing it in public. The discipline is the speed. What breaks when you build in public is the assumption that nobody's checking your work. Someone always is, including future you.