Building in Public: What We've Learned

Building in public is fashionable right now. Every founder with a Twitter account posts their MRR growth charts and weekly updates and tries to build an audience while building a company.

I want to give you an honest account of what it's actually like, based on what we've experienced with DenchClaw — because the fashion glosses over some real tradeoffs.

The Show HN Post#

Our Show HN post hit 147 points and 124 comments. Garry Tan tweeted about it. GitHub stars spiked. The day of the post was one of the most encouraging days in the company's history.

What people don't talk about: it's over in 36 hours. By day three, the Hacker News post is on page four. The GitHub spike plateaus. You're back to building.

The lasting value of the Show HN was:

1. About 30 users who've stayed active since the post
2. Several direct messages from founders and developers who became advisors or gave valuable feedback
3. Credibility when talking to investors ("featured on Hacker News, 147 points")
4. SEO — the post still drives some organic search traffic

The lasting value was real. The moment was brief.

What Garry Tan's Tweet Actually Did#

Garry tweeting about DenchClaw drove a spike. The spike was meaningful. But I'd be misleading you if I said it was transformative. Startup Twitter audience conversion is notoriously low — most people click, look briefly, and move on.

What it actually did:

• Gave us credibility with investors who pay attention to what Garry pays attention to
• Got a few high-quality developers to look at the code and submit issues
• Generated some YC-connected press attention

What it didn't do: replace the grind of individual user conversations, cold outreach, and consistent product improvement.

The lesson: earned media moments are valuable inputs, not substitutes for customer development.

What We Share and What We Don't#

The "building in public" approach requires judgment about what to share. We've developed rules:

Share freely:

• Product milestones ("v1.5 ships today with kanban view")
• Behind-the-scenes technical content ("here's how we built the DuckDB PIVOT schema")
• Honest product philosophy posts (like this one)
• GitHub issues and discussions

Be careful with:

• Revenue numbers — premature revenue sharing creates wrong expectations
• User numbers — context is everything; 100 highly-engaged users is often better than 10,000 passive ones
• Fundraising details — prematurely announcing raises can create noise and competition for your round

Never share:

• User-specific data, even anonymized in ways that are obvious
• Internal team disagreements
• Anything that would embarrass users who trust you with sensitive data

The Real Cost of Building in Public#

Nobody talks about this. Building in public takes real time. Every tweet, every blog post, every Show HN is time not spent on code or users. Early on, when you're trying to find product-market fit, that tradeoff is real.

We've been pretty disciplined about only writing things that double as useful documentation or genuine product education. This post, for example — writing about building in public is both authentic to our experience and potentially useful to founders considering the same approach. It's not building in public for building in public's sake.

The founders I've seen waste the most time building in public are the ones treating it as a marketing strategy. If it's a strategy, you're optimizing for the wrong thing. If it's authentic, it's worth something.

What Actually Works for Distribution#

Building in public is one channel. Here's what else has actually driven DenchClaw's growth:

Hacker News — Launch posts, "Ask HN" about the problem we're solving, thoughtful comments in relevant threads GitHub — Quality open-source code attracts stars, issues, and contributors organically Direct product value — Users who genuinely benefit from DenchClaw tell others about it SEO — Writing genuinely useful content (like this) compounds over time

The pattern across all of these: authenticity compounds; performance decays. Content that pretends to be more successful than you are gets sniffed out. Content that's genuinely useful keeps bringing value.

Frequently Asked Questions#

Should early-stage founders build in public?#

If it comes naturally, yes. If it feels like a job, no. The cost-benefit depends on your specific situation. If you're pre-product and pre-users, spending 5 hours a week on Twitter is probably a mistake. If you're post-launch and building an audience that converts to users, it can be worth it.

What should a first Show HN post include?#

What you built, why you built it, what's interesting or unusual about it, and a direct link to try it. Keep it under 300 words. The HN community wants to see the product, not the pitch.

How do you handle negative comments and criticism on Hacker News?#

With gratitude, genuinely. Negative HN comments are usually the most specific feedback you'll get outside of user interviews. Respond to them substantively. "You're right, that's a known limitation, here's our plan for it" is always the right answer.

How do you avoid revealing sensitive competitive information when building in public?#

Think about what you'd be comfortable with a direct competitor reading. Architecture decisions, product philosophy, user feedback themes — these are usually fine to share. Specific enterprise customer names, your detailed go-to-market playbook, or your fundraising status — protect these.

Ready to try DenchClaw? Install in one command: npx denchclaw. Full setup guide →