439: The Increasing Risk of Building in Public

Summary of 439: The Increasing Risk of Building in Public

by Arvid Kahl

16mApril 3, 2026

Overview of 439: The Increasing Risk of Building in Public (Bootstrap Founder — Arvid Kahl)

Arvid Kahl reflects on how “building in public” helped him sell FeedbackPanda and launch his career, then explains why the tactic that once worked so well is now much riskier. He argues the arrival of agentic AI tools and broader social scrutiny mean sharing granular product, technical, or financial details can actively invite fast, low-cost clones. He outlines a new, cautious approach to building in public: share what’s useful and interesting, but never content that provides a blueprint for replication.

Key takeaways

  • Building in public used to be a major growth and reputation strategy—Arvid’s public MRR disclosure helped lead to his exit.
  • The risk of cloning has increased dramatically because AI agents can ingest public signals and rapidly generate working copies of products.
  • Historical safe threshold (founders stopped sharing around $20–30k MRR) has effectively collapsed; even small startups are now more vulnerable.
  • Product, engineering skill, and tech stacks are no longer reliable moats—agents and LLM-driven tools lower the barrier to replicate.
  • Human relationships (long sales cycles, enterprise deals) and trust remain harder for agents to replicate and therefore remain important moats.
  • New rule for building in public: make posts interesting but never provide a reproducible blueprint.

Why AI changes the calculus

  • Agentic LLMs can be given prompts that:
    • Scrape a founder’s public posts,
    • Summarize business positioning and product flows,
    • Generate working prototypes, style guides, and marketing assets,
    • Wire up payment/auth/auth flows using production-ready frameworks.
  • This reduces time-to-clone from weeks/months to days, and makes it possible for non-experts to produce credible competitors.
  • Agents contain distilled, cross-domain knowledge (from docs, blogs, forums) and can act like a combined industry mentor—enough to produce viable substitutes.

What Arvid recommends sharing — and what to avoid

Avoid sharing (high risk)

  • Revenue numbers, MRR, customer counts, and financial specifics.
  • Customer names, account details, or anything that reveals customer behavior patterns.
  • System architecture diagrams, data ingestion pipelines, configurations, and exact dependencies/packages.
  • Feature-by-feature breakdowns that include metrics (e.g., “this feature produced X new customers”).
  • Any content that, if assembled, would form a step-by-step blueprint.

Safe / recommended to share (lower risk)

  • High-level, non-actionable product updates (e.g., “we added X integration and customers like it” without specifics).
  • Operational anecdotes: tripwires, mistakes, edge-case bugs and learnings without revealing the full system.
  • General industry insights and takeaways that don’t map directly to replicable implementation details.
  • Testing notes and small, non-architectural tips (e.g., package behaviors in test environments) that help peers but don’t give a blueprint.

Filter test: Is this interesting but not easy to clone? If yes, share. If it would make copying straightforward, don’t.

Practical, tactical checklist (what to do now)

  • Stop posting revenue, customer numbers, pricing-responses tied to features, or financial metrics publicly.
  • Redact customer names/identifiers and aggregate metrics when discussing wins/failures.
  • Avoid publishing architecture diagrams or exact service/config details for core systems.
  • When describing features, keep it high-level—focus on user benefits, not implementation specifics.
  • Share lessons, tripwires, and operational stories that teach without blueprinting.
  • Use private channels for peer feedback or early adopters when you need detailed input.
  • Monitor mentions of your company and conversations about your product (Arvid recommends PodScan for podcast mentions).
  • Treat public posts as part of an intentional “information dissemination strategy,” not casual journaling.

Notable quotes / succinct lines

  • “Make it interesting, but not easy to clone.”
  • “Product is not a moat anymore. Software engineering capability is not a moat, not anymore.”
  • “If it’s still insightful into your business, if it makes it easy to copy you, you’re building your own competitor.”

Final thoughts

Building in public is not dead, but it requires discipline and strategic filtering. The upside—reputation, audience, trust—remains valuable, but formats and content must be rethought in an age where agentic AI can turn public signals into fast clones. Protect the parts that would form a blueprint; share the human lessons and high-level insights that build community without handing competitors a ready-made blueprint.

Resources mentioned

  • PodScan (Arvid’s product): monitors podcasts and turns unstructured chatter into competitive intelligence; alerts on mentions and extracts startup ideas (ideas.podscan.fm).