Dear founder,
Building in public once helped me sell my company. Today, that same transparency could destroy yours.
That's not hyperbole. I owe my entire career as a writer, podcaster, and founder to being radically transparent about my business. I shared my Stripe-verified monthly recurring revenue numbers with the world, and that visibility attracted financial and acquisition interest that ultimately led to the sale of my previous software business, FeedbackPanda. That exit put me on the map. It gave me financial independence. It's the reason I have a podcast and a newsletter. If it hadn't been for building in public and sharing my numbers, I probably wouldn't be speaking or writing to anyone right now.
So when I tell you that the game has fundamentally changed, I need you to understand: I'm not saying this from the sidelines. I'm saying it as someone who benefited enormously from the old playbook and now watches founders follow it straight into danger.
What Building in Public Used to Mean
When I first encountered building in public about five years ago, it was all about transparency. You shared your numbers. You shared your strategies and tactics. You let people see behind the curtain. And it worked. It built enormous goodwill for founders. It created buzz for their products. It was a form of validation. People bought into your journey and became part of it themselves—amplifying your story, becoming early adopters, taking a risk on your unfinished product because they believed in you and what you were building.
And while the aspect of building reputation and demonstrating expertise in public is still an ongoing way for people to participate in the larger community of founders and entrepreneurs, the means of what building in public constitutes have changed significantly. It's the advent of artificial intelligence in particular, but also the increasing scrutiny and public awareness on social media, that have made things very different.
The Old Threshold
The risk of being copied has always existed. I wrote about this a couple of years ago, after analyzing when founders dropped out of the building in public race. There was a clear pattern. Companies stopped reporting their financial metrics and sharing specifics about what exactly they were building around $20,000 to $30,000 in monthly recurring revenue. That was the threshold. Below it, the risk was manageable. You weren't big enough to be worth cloning, and the upside of sharing—getting early adopter customers from your peer community, attracting innovators willing to give your product a chance—outweighed the downside. Above it, the likelihood of inspiring someone to build a competitor was too high, and the return on sharing was too low to justify the exposure.
That threshold has effectively collapsed to zero.
The Day Everything Changed
I would argue that the day the first CLI agentic coding agent found its way into a large enough group of people—the day it started being shared as the way forward for software engineering—that was the day building in public became not just risky, but outright dangerous.
I can tell you this because I've seen it happen. And it's not theoretical anymore.
Here's what a savvy, business-minded person can do today. They don't need to know how to code. They don't need to do extensive market research. They don't need to understand your tech stack. They just need a monthly subscription to an LLM company and the ability to phrase a prompt. Something like: "Investigate everything this person has said about their business over the last six months. Distill it into a report. Then create a free trial on their software platform. Go through each page, take screenshots, do a full semantic and HTML analysis. Write a report on the product. Create a style guide. Create a reference document explaining the business and its ideal customer profile based on how the landing page talks about them. Then build a product that does the exact same thing, maybe with a twist—something in addition that the existing product doesn't already do—using a framework that comes with production-ready payment and authentication systems."
Then they press enter.
Now, obviously, this isn't going to one-shot a perfect copy. But if a business-savvy entrepreneurial developer does this, it might take them a couple of days. Maybe a couple of weeks to turn that prompt from wish into a pretty solid reality. And if they understand paid advertising better than you do, or if they already have distribution in your market or an adjacent one, or they have some other leg up—then all of a sudden, there's a new competitor in the field that you have to deal with. One you essentially helped create.
What's Not a Moat
Clearly, there's a lot to running a business that has nothing to do with the product itself. I talked about this a couple of weeks ago—data is the moat. The existing business knowledge and insight that has to be accumulated almost painfully over many years of running a business or being deeply embedded in an industry, all of that doesn't come bundled with an agentic coding tool. Even though these tools have a lot of knowledge available from the blog posts, books, and forum posts they've ingested. They can be a mentor that acts as if they were someone from a particular industry, plus someone from every other industry that intersects with it. So there's that capability.
But here's what I know for certain: product isn't a moat. Software engineering capability isn't a moat. Not anymore.
So What Do You Actually Share?
The first instinct might be to say, "Well, then I'm never going to talk about my business at all." And honestly, that's not the worst idea. At the very least, it prevents other founders from being made aware of your business in enough detail to replicate it. You'll find ways of talking to customers without exposing everything to your peers.
But building in public, in front of a founder audience, is now a nuanced information dissemination strategy. Here's my personal approach.
I would never share numbers. Not how many customers you have, not how much revenue you make, not your expenses. And even with features—because they, too, are now pretty much a well-formulated prompt away from being built—I would be very careful about what I share and in what detail.
There's a meaningful difference between saying "we recently started integrating an MCP into our product, and customers really like it" versus "ever since we integrated an MCP for these five core features, over twenty new customers have chosen our medium-tier subscription plan." Those details, for anyone—machine or human—give far too much insight into the financial underpinnings of your business.
I've found myself not sharing any numbers or specifics at all at this point. What I do share are tripwires—things I didn't expect, and what happened when they occurred. Industry insights that are general enough to not immediately make sense to a direct competitor, but are genuinely interesting to other people. Operational experiences, like an interesting customer service conversation or fixing a particularly gnarly bug, and what went into solving it—without showing too much of the big picture.
What I Would Never Share
There are a few categories of information that I probably would have shared five years ago because they were interesting. Today, I wouldn't dream of it.
System architecture is one. Specifically how I set up my data ingestion pipeline, how I built my data distribution systems. Podscan is a pretty sizable business. It takes in tens of thousands of podcast episodes every day. It has both a REST and a webhook API that sends similar, if not even more, data packages per hour. That data needs to come from somewhere. It needs to be stored somewhere. It needs to go somewhere. And the systems I use for that are hard-won consequences of experimental efforts over more than two years. Why would I create a systems diagram and just give it away for free, handing another agentic system a blueprint to rebuild what I'm doing?
Same goes for dependencies. What service exactly do I use for data extraction? What's the exact package I use for transcription? I'm not going to share that, because why would I make it easier for anyone else to build the same thing?
Of course, I can talk about open source components I've used, or specific little tricks to get more performance out of existing technology. But you want to prevent sharing a blueprint. You don't want to create breadcrumbs to a clone.
The Principle: Interesting, Not Easy
That's really what this comes down to. You want to share things that make it interesting to participate in your journey, but not easy to clone your business. Everything you share should pass that test. If it's not interesting, nobody's going to engage with it anyway, and you're only increasing your risk surface for no benefit. If it makes it easy to copy you, you're building your own competitor.
Interesting to participate in. Not easy to clone. That's the filter.
Is Building in Public Dead?
So, maybe a bit theatrically: is building in public dead?
I don't think so. But it's been pruned. It's been cut down into a very nuanced and very delicate balance of risk management, sharing strategy, and business defense against copycats and clones.
If you're building in public and want to keep doing it, that's fine. You very likely already have defenses against copycats—otherwise, how would you have dealt with them before? But it is by far not as straightforward to share transparently and widely as it used to be before agentic systems. I know that people have always hired developers to build copies of existing products, just like they now hire Codex or Claude Code or whatever tool to do the same thing—but for much cheaper, and significantly faster.
There is real value in a certain level of not being in the spotlight. When it comes to successful software businesses, at some point you're going to have a customer moat. You'll have customers, large customers especially, that you can only have by having built relationships with them. Relationships that took six months of back and forth, four meetings with the team, careful negotiation to get a deal in place. No agentic coding tool is going to replicate that for your competitor.
But for small and growing businesses—the ones still in that vulnerable stage—you might want to keep things on the down low for a bit. Otherwise, you're inviting your own competitors to the table. And in this new world of AI-powered development, they can show up a whole lot faster than you'd expect.
We're the podcast database with the best and most real-time API out there. Check out podscan.fm — and tell your friends!
Thank you for reading this week's essay edition of The Bootstrapped Founder. Did you enjoy it? If so, please spread the word and share this issue on Twitter.
If you want to reach tens of thousands of creators, makers, and dreamers, you can apply to sponsor an episode of this newsletter. Or just reply to this email!
No comments:
Post a Comment