The Threshold Collapsed: What ProductLog Taught Me About Building in Public

I built ProductLog so founders can record their work as it progresses. The platform is live, and it remains a meaningful part of my work. But its premise also creates a tension: a well-kept public record makes a product’s story easier to follow and understand than scattered blog posts do. When AI can gather and process those records more quickly, that same clarity may become a useful shortcut for competitors.

In April 2026, Arvid Kahl revisited the argument that had helped define build in public for many founders. He had once seen a practical threshold: companies became more guarded when they reached roughly $20,000–$30,000 in monthly recurring revenue. In his view, agentic coding changed that calculation. The old threshold had, as he put it, “effectively collapsed to zero.”

That is Kahl’s assessment, not a measured law of software competition. His point is still worth taking seriously. A determined competitor can now collect public material, inspect a product, and use AI to reduce the time needed to build a rough alternative. Kahl does not claim that one prompt produces a perfect clone; he describes a faster path to a credible first version.

The ProductLog Paradox

Build in public has always involved a tradeoff. Share enough to attract feedback, trust, and early users; hold back enough to avoid publishing an operating manual for a competitor.

ProductLog makes the first half easier. A maker can put decisions, changes, experiments, and the reasons behind them into a readable sequence. That can be useful to other founders. It can also make my own thinking easier to reconstruct.

I noticed that tension in my own ProductLog entries. Some of them combine a customer hypothesis, a market approach, a future direction, and implementation lessons. No single entry is a complete specification. Together, however, they can lower the cost of understanding what I am trying to build and where I may be vulnerable.

That is the real problem. It is not that every public note instantly becomes a clone. It is that a series of precise notes can remove much of the discovery work a competitor would otherwise have to do.

Faster Imitation Does Not Make Everything Equal

AI has made visible features and basic product flows easier to imitate. It has not made the cost of building or operating a real business zero.

Writing code is only one part of the work. A product still has to earn attention, understand a customer, handle exceptions, make decisions under uncertainty, and keep working after the first demo. Distribution, customer relationships, accumulated domain knowledge, and the ability to operate a system are all harder to reproduce from a public page.

Harder is not the same as impossible. None of these is a permanent moat. They are simply assets that take time, judgment, and repeated work to build. That distinction matters because it avoids two equally lazy conclusions: that code no longer matters, or that hiding code is enough to protect a business.

For ProductLog, the question is therefore not whether I should stop sharing. It is whether a particular detail helps people understand a real lesson or merely makes an unfinished plan easier to copy.

Share the Lesson, Protect the Active Recipe

The useful material in build in public is often the reasoning: why a decision was made, what constraint changed it, what failed, and what was learned afterward. That can give another founder something to think with without revealing every active assumption, future priority, or operational detail behind the product.

There are details I now treat differently. I can write about a wrong turn after I understand it. I can discuss the kind of problem a product is trying to solve. I do not need to publish the entire sequence of choices that would let someone reproduce an unfinished strategy more quickly than I can test it.

This is not a retreat from ProductLog. It is a better definition of what responsible transparency looks like when public material is easier to collect, summarize, and reuse.

The practical framework belongs in Build in Public in the AI Era: What to Share and What to Keep Private. That article is about evaluating individual artifacts: a screenshot, a metric, a technical note, or a plan. This essay is about the more personal contradiction behind that framework. I built a place for founders to show their work, then had to decide how much of my own work should be shown there.

The answer is not silence. It is to make the public record useful to people who want to learn from the work, without turning it into a shortcut around the work itself.