If you’re on tech Twitter or IndieHacker circles, you’ve probably seen the term “building in public” thrown around like it’s some golden rule. And for many indie developers, it is — but only if you’re building for other devs.
Let me explain.
The Problem
Everyone’s out here sharing MRR updates, dashboards, lines of code, and weekly retrospectives. But here’s the catch: most of your actual customers don’t care.
If you’re building something for non-technical users, constant behind-the-scenes updates can make your brand look unfinished, chaotic, or even desperate. And in consumer-facing industries (like lifestyle, fashion, or non-dev SaaS), your customers don’t want to see the builder struggle — they want a polished, confident product that solves their problem.
Not All Transparency is Marketing
There’s a difference between transparency and vulnerability. Sharing every bump on the road might make you relatable on Twitter, but it can reduce your perceived value in the eyes of your customers. You’re essentially telling them:
“Hey! I’m still figuring this out — wanna pay me while I do?”
That doesn’t exactly inspire confidence.
Now don’t get me wrong, I’ve built in public too. I’m building SaaSRocket — a production-ready boilerplate for SaaS founders with pre-integrated Supabase, Resend, Lemon Squeezy, and more. I shared progress with devs because it’s made for devs.
But if I was building something for, say, eCommerce shop owners or restaurant managers, I’d focus on results, testimonials, and polish — not my debug logs and feature toggles.
So What’s the Takeaway?
If your product is for other developers, sure — building in public can help.
But if it’s not?
You might just be hurting your brand by constantly exposing its unfinished side.
Instead:
- Build quietly.
- Launch loudly.
- Let your users speak for you.
And if you are building something for devs, maybe skip the chaos and use SaaSRocket. It’s got all the boring parts done — so you can skip to shipping.
