439: The Increasing Risk of Building in Public

1 - > Arvid: Hey. It's Arvid, and this is The Bootstrapped Founder. 2 - > Building in public, I wanna talk about that today. It once helped 3 - > me to sell my company, and today, I think that same level 4 - > of transparency that I used and built in public with a couple of 5 - > years ago, four, five, six years ago, well, it's been a while, 6 - > that actually, I think, can destroy your company if you 7 - > employ it the exact same way today.

And I think that's not 8 - > hyperbole. 9 - > I owe my entire career as a writer, as a podcaster, and a 10 - > founder to being pretty much radically transparent about my 11 - > business. I shared my Stripe verified monthly recurring 12 - > revenue with the world, and that visibility back then in twenty 13 - > eighteen, nineteen attracted financial and acquisition 14 - > interest that ultimately led to the sale of my previous software 15 - > business Feedback Panda. I talk about this in the very first 16 - > episode of this podcast too.

And that exit put me on the map. It 17 - > gave me financial independence. 18 - > It's the reason I have a podcast and a newsletter to begin with. 19 - > If it hadn't been for Building Public and sharing my numbers, I 20 - > probably wouldn't be speaking or writing to anybody right now.

So 21 - > when I tell you that the game has fundamentally changed, I 22 - > need you to understand that I'm not saying this from the 23 - > sidelines just observing. I'm saying this as somebody who 24 - > benefited enormously from this old playbook, and I'm now 25 - > watching founders follow it straight into danger. So that's 26 - > why I wanna talk about building in public and the risks that 27 - > come with it today. 28 - > When I first encountered the idea of building in public 29 - > around five years ago, six years probably, it was all about 30 - > transparency.

You shared your numbers, you shared your 31 - > strategies, your tactics, and you let people see behind the 32 - > curtain, it worked. It built enormous goodwill for founders. 33 - > It created buzz for their products and was kind of a form 34 - > of validation too. People bought into your journey and then they 35 - > became part of it themselves.

36 - > They amplified your story. They became early adopters and they 37 - > never let me repeat the last part. And they took risks on 38 - > your unfinished product because they believed in you and what 39 - > you were building. And while this aspect of building 40 - > reputation and demonstrating expertise in public is still an 41 - > ongoing way for people to participate in our larger 42 - > community, the founders, the entrepreneurs, the means of what 43 - > building in public constitutes have changed quite a bit.

It's 44 - > kind of the advent of artificial intelligence in particular, but 45 - > also the increasing scrutiny and public awareness on social media 46 - > that have made things quite different. 47 - > The risk of being copied. That's the big thing in Building 48 - > Public, right? It's always existed.

Once you share, once 49 - > you talk about something, people listen. I wrote about this a 50 - > couple years ago after analyzing when founders dropped out of the 51 - > building a public race. 52 - > I kind of wanted to see, can we time this? Like, when do people 53 - > stop?

And there was a clear pattern there. Companies stopped 54 - > reporting their financial metrics and sharing their 55 - > specifics about what exactly they were building. Just around 56 - > 20,000 to $30,000 in monthly recurring revenue. 57 - > That was the threshold then.

And below it, risk was manageable. 58 - > You weren't big enough to be worth cloning and the upside of 59 - > sharing, getting early adopter customers from your peer 60 - > community and attracting innovators willing to give your 61 - > product the chance, well, that outweighed the downside of maybe 62 - > having somebody try and clone your business. And above it, 63 - > above 20 to 30 ks, the likelihood of inspiring somebody 64 - > to build a competitor was just too high. And the return on 65 - > sharing was too low to justify this kind of exposure.

66 - > And I think this particular threshold has effectively 67 - > collapsed to zero or is on its way of collapsing to zero. I 68 - > would argue that the day the first CLI agentic coding agent 69 - > found its way into a large enough group of people, the day 70 - > that it started being shared as the way forward for software 71 - > engineering, was the day that building in public became not 72 - > just risky, but outright dangerous. And I can tell you 73 - > this because I've seen it happen.

It's not theoretical 74 - > anymore. Here's what a savvy business minded person can do 75 - > today. 76 - > They don't need to know how to code. They don't need to do this 77 - > extensive market research.

They don't even need to understand 78 - > the tech stack. They just need a monthly subscription to an LLM 79 - > company and the ability to phrase a prompt clearly. 80 - > Something like investigate everything that this particular 81 - > person has ever said on social media about their business over 82 - > the last six months, distill it into report, then create a free 83 - > trial on their software platform, go through each page, 84 - > take screenshots, do a full semantic and HTML analysis, 85 - > write a report on the product, create a style guide, create a 86 - > reference document explaining the business and its ideal 87 - > customer profile based on how the landing page talks about 88 - > them, then build a product that does the exact same thing, maybe 89 - > with a twist, something in addition to the existing product 90 - > that it doesn't already do, using a framework that comes 91 - > with production ready payment and authentication systems.

92 - > That's the prompt. And then they press enter and stuff happens. 93 - > Now obviously this isn't going to do a one shot perfect copy, 94 - > but if a business savvy entrepreneurial developer uses 95 - > this, it might take them a couple of days to build 96 - > something, maybe a couple of weeks to turn that prompt from a 97 - > wish into a pretty solid reality. And if they understand 98 - > paid advertising better than you might, right, if they already 99 - > have distribution in your market that you don't or in an adjacent 100 - > market that you wouldn't even think about, some leg up they 101 - > might have, then all of a sudden there's a new competitor in the 102 - > field that you have to deal with, one that you essentially 103 - > helped create by talking about all these specific things.

104 - > Problematic, right? 105 - > Clearly, there's a lot to running a business that has 106 - > nothing to do with the product itself, and that's also 107 - > something that building it in public often touches. I talked 108 - > about this a couple weeks ago. Data is the only mode was the 109 - > episode.

The existing business knowledge and insight that has 110 - > to be accumulated almost painfully over many years of 111 - > running a business or being deeply embedded in an industry, 112 - > well, all of that doesn't come bundled with agentic coding 113 - > tools like Claude Code. Even though Claude is pretty smart 114 - > and you can act as if it was somebody with experience, it 115 - > only has the distilled insights that people have already shared. 116 - > These tools have a lot of knowledge available from these 117 - > blog posts and books and forum posts that they've ingested as 118 - > training data in the past.

They can be a mentor that acts as if 119 - > they were somebody from this industry, plus somebody from 120 - > every other industry that intersects with it. So that's a 121 - > capability that these tools have. And that's kind of scary 122 - > if you think about it because I'm always realizing over the 123 - > last couple months in particular that I'm not the best developer. 124 - > Obviously, I'm not even a good developer.

125 - > I I would consider myself a developer at best, but I know 126 - > what good code looks like. I have a hard time writing it, but 127 - > I can tell if it is good or not. Kind of have a sense, a taste, a 128 - > judgment capacity for it. So the same extends to marketing, to 129 - > sales, to product development, to relationship development, to 130 - > competitor analysis.

I'm not trained in any of these, and I'm 131 - > not particularly good, but I can tell a good outcome from a bad 132 - > outcome, like a good report from bad report, an insight 133 - > insightful report from a useless report. 134 - > And that is enough if I have agentic tools that do this work 135 - > for me with the full underpinning of the collected 136 - > wisdom of humanity in their training data. So where's that 137 - > moat, right? I know for certain that product is not a moat 138 - > anymore.

Software engineering capability is not a moat, not 139 - > anymore. So what do we talk about when we do want to build 140 - > in public? 141 - > Because it's still good, right? Well, the first instinct might 142 - > be to say, well, I'm never going to talk about my business at 143 - > all.

Honestly, it's not the worst idea at this point. At the 144 - > very least, it prevents other founders from being made aware 145 - > of your business in enough detail to replicate it. You'll 146 - > find ways of talking to customers without exposing 147 - > everything to your peers, if you kind of do it in a more private 148 - > way. 149 - > But building in public is still beneficial because you built 150 - > this kind of reputation, you built some kind of connectivity 151 - > with your peers, with the other founders in the field, the other 152 - > experts in the field.

So it's a good thing to do. And building a 153 - > public in front of an audience that includes founders has to 154 - > change just a little bit. It has to be a nuanced information 155 - > dissemination system. It has to be a strategy.

156 - > So here's my personal approach that I use to still build in 157 - > public without giving everything away. First off, I would never 158 - > share numbers. Not how many customers I have, not how many 159 - > dollars I make in revenue, not what my expenses are. And even 160 - > with features, because they too are now pretty much a well 161 - > formulated prompt away from being built by anybody, I'm 162 - > careful about what I share and in what detail.

Because there's 163 - > a meaningful difference between saying we recently started 164 - > integrating an MCP into our product and customers really 165 - > like it, which is quite literally what we've done at 166 - > Podscan, versus ever since we integrated in MCP for these five 167 - > core features, over 20 new customers have chosen our medium 168 - > tier subscription plan. 169 - > Now these details for anyone, for machine or human, they give 170 - > far too much insight into the financial dynamics of the 171 - > business and even the customer behaviors.

Like, don't overshare 172 - > with specificity. I found myself not sharing numbers or specifics 173 - > at all at this point, but when it comes to revenue, when it 174 - > comes to customer names, customer numbers, customer 175 - > accounts, all that, what I do share are things that trip me up 176 - > along the way. The tripwires, things I didn't expect, and what 177 - > happened when they occurred, what I did, what I learned from 178 - > this. Industry insights that are general enough to not 179 - > immediately make sense to a direct competitor, but are 180 - > genuinely interesting to anybody else, like in the industry or 181 - > outside of it, that stuff works.

182 - > Operational experiences, like an interesting customer service 183 - > conversation or fixing a particularly gnarly bug and what 184 - > went into solving it without showing too much of the big 185 - > picture. There are a few categories of information that I 186 - > probably would have shared easily five years ago because 187 - > they were interesting and today I wouldn't dream of it anymore. 188 - > System architecture is one. Specifically, how in my case for 189 - > Podscan, I've set up my data ingestion pipeline, how I built 190 - > my data distribution systems, right?

Podscan is a pretty 191 - > sizable business at this point. 192 - > It takes in tens of thousands of podcast episodes every day. It 193 - > has like a REST API, a webhook API, an MCP, all that. And that 194 - > sends similar, if not more data packages per hour, also like 195 - > tens of thousands per hour out to all the customers.

The data 196 - > needs to come from somewhere, it needs to be stored somewhere, it 197 - > needs to go somewhere, and the systems that I use for that are 198 - > hard won consequences of many many experimental efforts over 199 - > more than two years at this point. Why would I create a 200 - > systems diagram of this and just give it away for free, handing 201 - > another agentic system effectively a blueprint to 202 - > rebuild what I'm doing? 203 - > Well, not gonna, right?

And neither should you. This stuff 204 - > is internal. And it might be obvious that this is internal, 205 - > but for some people it's just interesting. Interesting to 206 - > know, interesting to share, it becomes problematic.

207 - > And the same goes for dependencies. So what kind of 208 - > service exactly do I use for data extraction or retrieval? 209 - > What's the exact package and its configuration that I use for 210 - > transcribing like 50,000 podcast episodes a day? Well, I'm not 211 - > going to share that, because why would I make it easier for 212 - > anybody else to build the same thing?

Of course, I can talk 213 - > about the open source components that I've used or specific 214 - > little tricks to get more performance out of an existing 215 - > technology. 216 - > That's always nice. Maybe I talk about this all the time now that 217 - > I'm more into testing, like I talk about which particular 218 - > packages have this little bug when you test them this way. 219 - > That's wonderful, that's great, that's helpful.

But you want to 220 - > prevent sharing a blueprint. You don't want to create breadcrumbs 221 - > to clone for somebody else. 222 - > And that's really what it comes down to. You want to share 223 - > things that make it interesting to participate in your journey, 224 - > but not easy to clone your business.

Everything you share 225 - > should pass this particular test. If it's not interesting, 226 - > well then nobody's going to engage with it anyway, and 227 - > you're only increasing your risk surface for no benefit, right, 228 - > if it's still insightful into your business. If it makes it 229 - > easy to copy you, you're building your own competitor. 230 - > So those two things should always be in place: make it 231 - > interesting but not easy to clone.

That's the filter. So 232 - > maybe then, let's ask a bit theatrically, is building in 233 - > public dead? Well, I don't think so, but it's been pruned. It's 234 - > been cut down to a very nuanced and very deliberate balance of 235 - > risk management, sharing strategy, and business defense 236 - > against copycats and clones.

237 - > If you're building a public and you want to keep doing it, 238 - > that's fine. You very likely already have defenses against 239 - > copycats there. Otherwise, how would you have dealt with them 240 - > before? Because people have already tried to copy stuff over 241 - > the last five, ten years, as long as building a public 242 - > existed.

But it is by far not as straightforward to share 243 - > transparently and widely as it used to be before agentic 244 - > systems. 245 - > I know that people have always hired developers to build copies 246 - > of existing products out there, and just like they now hire 247 - > Codex or Cloud Code or whatever tool to do the same thing. But 248 - > now it's much cheaper, significantly faster and frankly 249 - > much better, right? It doesn't sleep, it doesn't tire, it has 250 - > all the knowledge already baked in.

Something that other people 251 - > would have taken days, if not weeks, to figure out is now a 252 - > couple seconds away, because it's already in the model. 253 - > There's real value at this point of not being in the spotlight. 254 - > When it comes to successful software businesses today, at 255 - > some point you're going to have to have a customer mode. You'll 256 - > have customers, large customers especially, that you can only 257 - > have by having built relationships with them.

So 258 - > that's another mode that an agentic tool won't be able to 259 - > have, right? Relationships that took six months of back and 260 - > forth emails and four meetings with the team and some Zoom 261 - > calls and careful negotiation to get a deal in place, no agentic 262 - > coding tool is going to replicate that for your 263 - > competitor just yet. I mean, we have seen with 11, like 264 - > automated tools that speak as if they're humans, Then we have 265 - > agents, the open claws of the world that just consistently 266 - > interact with people.

267 - > We're getting to this point. We're just not there yet. But 268 - > for small and growing businesses, the ones that are 269 - > still in this vulnerable stage, the early stage, you might want 270 - > to keep things under down low for a bit. Otherwise, you might 271 - > be inviting your own competitors to the table and not competing 272 - > humans, but humans that kind of spawn robots to compete with 273 - > you.

And in this kind of new world of AI powered development, 274 - > those things show up a whole lot faster than you will expect. 275 - > That's it for today. Thank you so much for listening to The 276 - > Bootstrapped Founder. You can find me on Twitter at Arvid Kahl 277 - > Arvid Kahl.

Okay. Same. 278 - > Let me let me do this whole thing again. You can find me on 279 - > Twitter at Arvid Kahl, Arvid Kahl.

If you're a founder who's 280 - > now thinking more carefully about what gets said about your 281 - > business out there, well, this is exactly why I built PodScan. 282 - > We monitor over 4,500,000 podcasts in real time, and we 283 - > alert you when anybody mentions you so you know what's being 284 - > said before somebody else uses it against you or uses it to, 285 - > you know, further their own agenda. And we turn unstructured 286 - > podcast chatter into competitive intelligence, so you can use 287 - > that to set yourself apart.

288 - > If you're looking for your next venture, you don't know what to 289 - > do, check out ideas.podscan.fm where we identify startup 290 - > opportunities from hundreds of hours of expert discussions on 291 - > podcasts daily, so you can build what people are already asking 292 - > for. Share this please with anybody who needs to turn 293 - > conversations into competitive advantages.

Thanks so much for 294 - > listening. Have a wonderful day and bye bye.