Six weeks ago we decided to ship Dock in the open.
Public changelog. Public roadmap. Public engineering ops, including the messy parts — the prod outage, the migration recovery, the day we accidentally archived the wrong workspaces. Every post on the engineering blog, every issue on the public board, every Friday demo posted to LinkedIn.
The premise was: we're building something that's hard to explain in marketing copy ("the AI workspace") but easy to understand if you watch us build it. So instead of crafting a launch narrative, let people see the work.
It's been six weeks. Some of it worked. Some of it didn't. Here's what's keeping, what's dropping, and the one rule we held that everyone tried to talk us out of.
The numbers
To set context:
- Nine PRs/day on average across the agent team and the human team. About 70% of those came from agents.
- 6,000+ readers on the public changelog over six weeks. We have an RSS feed and an email subscribe link.
- 41 blog posts, including this one. Half are technical. Half are positioning / opinion / "here's what we're building and why."
- 3 incident postmortems posted publicly. One outage (6 hours), one near-miss (caught in pre-prod), one user-facing bug we owned in real-time.
- 22 unsolicited inbound conversations from the changelog and blog. About a third converted to design partners.
The numbers won't impress anyone running a serious GTM motion. The point of "in public" wasn't to win funnel; it was to test whether the audience for what we're building exists, and whether they'd recognize it. They do, and they did.
What worked
Frequent shipping made the changelog real. A changelog with one entry per month is a marketing artifact. A changelog with several entries per week is a heartbeat. Readers came back because there was always something new — even when the new thing was small. The cadence created the readership.
Owning incidents publicly built more trust than not having incidents would have. When the prod migration jammed and we were down for six hours, we posted what was happening as it unfolded. The thread had more engagement than any of our launch posts. Readers told us afterward that "watching them recover from this is what made me trust Dock." Counterintuitive but true: the trust dividend from owning the failure exceeded the trust cost of the failure itself.
Letting agents do the writing was the right move. Most of our posts are drafted by Argus (our writing agent), edited by a human. The posts read like a team voice because the agent has been in our workspace long enough to have a voice. Agents don't replace founder writing; they make founder writing scalable. We covered this in Drafted by an agent.
Treating the blog as workspace exhaust kept it sustainable. When we did the work, there was a post in it. We didn't sit down to "write blog content"; we sat down to think about a problem, wrote it up in our workspace, and the workspace exhaust became a post. The fact that 41 posts shipped in 6 weeks is because none of them were standalone marketing efforts.
What we're dropping
The "tweet thread" version of every post. We tried cross-posting most blog content as Twitter/LinkedIn threads. The threads got engagement but they didn't drive traffic back. They were a separate piece of work that didn't pay back the time. We're dropping multi-channel cross-posts and just publishing on the blog + RSS.
Friday demo videos. We did six weekly demo videos. The first three were genuinely useful for showing the product. By the fourth, they were repetitive, and the work to make them was crowding out actual product work. We're moving demos to "when there's something genuinely new to show," which works out to roughly monthly.
What we held
The rule that everyone tried to talk us out of: own the rough drafts publicly, not just the polished ones.
The advice we got was something like "publish polished posts; keep the messy thinking private." Several people we trust said this. The argument was that rough drafts make the team look unfocused — readers don't want to see the thinking, they want to see the conclusions.
We didn't follow this advice. Most of our posts are visibly mid-thought. They start with "here's what we're seeing," not "here's the answer." They include things we've changed our minds about. They name the things we tried and abandoned.
This was risky because some readers came back and quoted earlier positions back at us. "You said X in March; now you're saying Y." The trade-off was real. We accepted the cost because the alternative — only publishing polished, defensible takes — would have made the blog feel like marketing, and the marketing-feel was exactly what we were trying to avoid.
The rule held. Most of the readers who became design partners cited the rough-draft posts as the reason they reached out. "It felt like you were thinking, not selling." That sentence appeared in inbound messages four separate times.
What we'd do differently next time
Start the changelog earlier. We waited until the product was demoable before shipping the changelog. We should have started a month earlier, when we had less to show but more thinking to share.
Number the posts. A few readers asked "is this part of a series?" Without explicit numbering, the relationship between posts wasn't obvious. We're going to start tagging cluster posts (which is what this current series of cluster posts does — see Agent collaboration: a primer for 2026 for the cluster spine).
Build the RSS earlier. We added RSS three weeks in. Should have been day one. Email subscribers are valuable; RSS subscribers are the most loyal audience you can build for a slow-moving content surface.
Six weeks in, the lesson
The thing the public-build experiment proved isn't "build in public is good." That's not surprising. The thing it proved is what in public has the highest leverage:
- The thinking, more than the announcements.
- The recoveries, more than the wins.
- The team's voice, more than the polished founder voice.
- The cadence, more than any single piece.
Build-in-public is a content strategy in the same way that an open-source project is a software-distribution strategy. It works because the openness is the substrate, not the marketing tactic. Doing it badly looks like "publish polished case studies on a schedule." Doing it well looks like the team's actual work surface bleeding into the public, with the messy parts attached.
We're keeping going. The next six weeks will be different — more product surface, fewer launch-prep stories, more "here's what we built" with the workings shown. Same rules.
If you've been reading along, you've been watching us think. That's the offer. We're glad you're here.
Cross-links
- Drafted by an agent — how the writing pipeline actually works.
- Names over titles — the team voice, including the agents.
- Agent collaboration: a primer for 2026 — the umbrella thesis the rest of the blog cluster sits under.
FAQ
What does "building in public" mean for a startup?
Publishing the work surface — the changelog, the engineering thinking, the incident postmortems — alongside the product. The audience watches you build, not just receive your launches. Done well, it builds trust faster than traditional marketing because the openness is what's persuasive.
How often should you publish?
Often enough to be a heartbeat. Weekly is the floor; near-daily is the ceiling. The cadence has to be sustainable — if it's a marketing project that crowds out engineering, it'll fail. The trick is making publishing a side effect of the work, not a separate effort.
Should you publish failures?
Yes. The trust dividend from owning a failure publicly is larger than the cost of the failure itself. The reader's mental model is "if they're this honest about the bad day, the good days are probably real." Hiding failures and over-polishing wins is the marketing-feel that build-in-public is supposed to escape.
Do agents help with public-building?
Yes, if you've built the substrate (identity, attribution, workspaces) for them to be teammates. Agents can draft the posts, summarize the changelog, even respond to comments — all attributed to the agent, edited by a human. We covered the writing pipeline in Drafted by an agent.
Is the audience for "in public" actually who you want as customers?
In our experience, yes. The readers who became design partners were exactly the kind of people we want as customers — engineers and founders thinking about agentic infrastructure. The audience self-selects toward your ideal customer profile. Marketing tactics that maximize reach often optimize for the wrong audience; "in public" tends to find the right one.
{
"@context": "https://schema.org",
"@type": "BlogPosting",
"headline": "Six weeks of building in public",
"description": "Nine PRs a day on average. A public changelog read by 6k+ people. The four things that worked, the two we're dropping, and the one rule we held that everyone tried to talk us out of.",
"datePublished": "2026-04-26",
"author": { "@type": "Person", "name": "Govind" },
"publisher": { "@type": "Organization", "name": "Dock", "url": "https://trydock.ai" },
"image": "https://trydock.ai/blog-mockups/style-d-dreamscape/six-weeks-of-building-in-public.webp",
"mainEntityOfPage": "https://trydock.ai/blog/six-weeks-of-building-in-public"
}