Building in Public: The Honest-Marketing Rule

Tier 3 · Real Build 8 min read

Building in public means posting about your work as it happens. The appeal is real: community feedback, accountability, and a public record of the arc. The risk is equally real: the framing drifts ahead of the receipts, the autonomy claims lose their asterisks, and the velocity stories compress multi-week arcs into one-day sprints.

JD’s public LinkedIn account (~40 posts over two months of building) is an unusually honest example of build-in-public. It routinely posts failures (“shipped some slop,” “pushed agents that did dumb stuff at 3 AM,” “the brain was a goldfish”). But even with that discipline, three specific patterns crept in. Understanding them is useful whether you are building in public yourself or evaluating someone else’s claims.

Over-claim trap 1: Project count inflation

JD’s LinkedIn posts cited “47 active projects,” “60+ projects in 4 months,” and at one point a forward-projection of “should ship 15+ a year.”

The registry has ~80 entries. What are those entries?

The project-registry.yaml tracks everything that ever got a project slug: shipped products, experiments, demos, archived ideas, one-off agents, and planning docs for things that were never built. The defensible number — from the CHANGELOG and the actual filesystem audit — is closer to “~69 entries in the active rollup, most experiments or tooling, a handful of shipped products.”

JD’s own deck build (CHANGELOG 2026-06-08) explicitly discarded “inflated research figures” in favor of filesystem-audited counts: approximately 30 agent packages, 907 Python files, 155 crons. The same discipline should apply to project counts.

The fix: pick one authoritative count method and use it consistently. For JD’s system, that is the filesystem-audited numbers. If you are building in public and your count depends on how you define the word “project,” define it explicitly in the first post and use that definition consistently.

The spirit of “prolific output” is completely true. The specific headline integers are softer than they sound. Both things can be true at the same time — if you say so explicitly.

Over-claim trap 2: Dropped autonomy asterisks

Several LinkedIn posts described the agent system with phrases like “manages end to end” and “runs my money / health / CRM, I never touch.”

The autonomy is real. But it has gates that some posts dropped.

From TRUE-STORY.md:

“The honest framing JD sometimes uses (‘touch only bank/domain/IP-signoff, not zero-human’) is the accurate one — but several posts drop that asterisk.”

The actual hard rules from the Organization Charter and CLAUDE.md:

Money moves require human approval
Communications sent as JD require human approval
IP and trademark decisions require human approval
The merch first sale was JD’s own test buy (he was the customer)

None of this diminishes what was built. An autonomous operator that handles everything up to money/identity/IP gates is genuinely impressive. But “fully autonomous” and “autonomous up to the gates” describe different systems, and the difference matters if you are evaluating whether to trust a similar system with your own finances.

The fix: keep the asterisk in every autonomy claim. Not as a legal disclaimer buried in footnotes, but as part of the description. “The operator runs the store — designs, lists, fulfills orders, handles customer emails — and I approve any action that touches money or IP.” That sentence is more accurate and still conveys the right scope.

The asterisk is also what makes the claim verifiable. “Fully autonomous” is a claim that can be falsified by one counterexample. “Autonomous up to these specific gates” is a claim with a clear scope that can be evaluated against the actual system behavior.

Over-claim trap 3: Velocity compression

The Nerve Center v5 cockpit went through a major architectural pivot between May 22 and May 31. A scathing self-audit found six of eight domain agents were hollow, the cost dashboard was showing $0.00 (a lie), and the original PTY-scraping architecture was the root cause of every reliability bug.

A LinkedIn post described a version of this as “rebuilt… in one day.”

The one-day sprint happened. A major cockpit build session did happen in one day. But that day was the culmination of a week-long process that included a research synthesis with three parallel agents, a full 5-agent audit, and multiple architecture pivots. The sprint-within-an-arc got compressed into just the sprint.

The fix: frame single-day sprints as sprints-within-an-arc. “After a week of architecture work, yesterday’s sprint landed the final pieces and pushed it to production” is accurate and still conveys the pace. “Built the whole thing yesterday” implies a different kind of work.

This one is subtle because sprint-day framing is genuinely dramatic and interesting to read. The multi-week arc with its false starts is harder to turn into a compelling post. The solution is not to make the arc boring — it is to be honest about which part of the arc the sprint represents.

What JD gets right

The three over-claim patterns above are worth naming because they appear in almost every build-in-public account. They are worth naming specifically about JD’s posts because those posts are otherwise unusually honest — and the gap between “unusually honest” and “fully accurate” is instructive.

What the posts consistently get right:

Failure posts. “Shipped some slop. Build agents did dumb stuff at 3 AM.” “The brain was a goldfish — forgot everything on session rotation.” “We hit a major incident and here’s exactly what went wrong.” These posts are rare in build-in-public. They are the posts that make the success claims credible.

Specific receipts. “7 bugs found last weekend” — traceable to the evolution scout CHANGELOG entries. “First real sale, Printful order 161851271” — traceable to the merch CHANGELOG entry. “30/30 on the MBA final” — triple-judge verified. The specific numbers tie the claims to real events.

The taxonomy. The framing of model vs. agent vs. harness vs. multi-agent system is precise and consistent. JD does not call everything an “AI.” He uses the words correctly and explains the distinctions.

The honest scale caveat. Multiple posts acknowledge the system is single-operator and depends on JD’s own discipline. “It is impressive and fragile” is not a common thing to say about your own system.

The docs site standard

This site applies the honest-marketing rule to everything it publishes:

Filesystem-audited numbers only. ~31 agent packages, ~907 Python files, ~155–160 crons, 200+ Supabase tables, 8 domains. No rounded-up headlines.
Human-gate asterisks on every autonomy claim. Every article that describes autonomous behavior names what the human gate is.
Receipts for every “what we built” claim. Every article in Tier 3 traces back to a CHANGELOG entry or a real file on disk.
Sprint framing names the arc. One-day sprints are described as one-day sprints. The surrounding context is present.

The purpose of these rules is not to make the work sound smaller. The work is real and worth writing about clearly. Accurate claims hold up under scrutiny. Inflated claims erode trust the first time a reader checks.

The summary test

Before posting about anything you have built, run it through three questions:

Count test: is this number derived from a real, defined count method? If someone asked me to enumerate all the items in this count, could I produce the list?
Autonomy test: have I named the human gate? If my answer to “who approves X?” is “no one,” is that actually true or did I just not mention it?
Velocity test: is this one-day sprint described as a sprint, or as the entire arc?

If all three pass, post it.

You have reached the end of the Tier 3 learning path. Go back to The Learning Path Map for a full overview of where to go next, or explore any Tier 3 article you skipped — each one is a standalone piece of the system described in this site.