What I Don't Share When Building in Public

Most building-in-public advice is written as a case for transparency: share your revenue, share your struggles, share your roadmap, and trust will follow. What almost nobody writes about is the other half of the decision — the specific moments where I'm looking at an update I'm about to post and deciding not to post it, and why that's usually the right call.

I've been building CreatorBit in public for a while now, alongside freelance work through my own dev practice, and the boundary between "honest" and "oversharing" turned out to be a lot blurrier than the usual advice suggests. Here's what I actually hold back, and what changed my mind about a few things I used to share freely.

Client and Project Details, Even When the Story Is Good

The easiest rule I follow, and the one I've never second-guessed, is that freelance client work doesn't get named, described in identifying detail, or used as a case study without asking first — even when the story reflects well on the client. A tricky migration, an unusual integration requirement, a client who pushed back on scope in a way that taught me something: all of that can turn into a genuinely useful post, but only once I've stripped anything that would let the client, or anyone who works with them, recognize themselves in it.

This isn't just caution about upsetting a client. It's that client work isn't mine to narrate. The lesson underneath the story is mine — how I handled scope creep, how I structured a contract after getting burned once, how I priced a project I'd underquoted the first time. That's what I share. The specifics of whose project it was stay out.

Exact Numbers, Especially Early Ones

I share revenue and usage trends in a general sense — up, down, flat, meaningfully changed — more often than I share the precise figure at a specific moment. Early-stage numbers in particular get outsized meaning attached to them by people reading from outside. A small absolute number looks discouraging even when the trend behind it is healthy. A number that jumped for one reason — a single referral, a short-lived spike in traffic — reads as a growth story when it was really a coincidence.

That's less about hiding bad news and more about not wanting a single snapshot to become the thing people remember, when the number itself wasn't stable enough to mean what it looked like it meant. If I'm going to share a number, I want to be able to explain it in the same sentence, not let it sit there as a data point people draw their own conclusions from.

Decisions I've Reversed, Until I Understand Why

I've changed direction on features and pricing more than once, and my instinct used to be to post about the reversal immediately — partly because building in public rewards that kind of honesty, and partly because sitting on a decision felt like hiding something. What I've learned is that posting a reversal before I actually understand why I got it wrong the first time produces a worse post and a worse decision.

There was a pricing change I made and then walked back within a couple of weeks. My first instinct was to write about it right away — "here's what I got wrong, here's what I'm doing instead." But I hadn't actually figured out why the first version was wrong yet; I'd just noticed it wasn't working and reacted. If I'd posted that in the moment, it would have read as transparency but functioned as narrating confusion in real time. I waited about a month, made the second change, watched whether it actually held up, and only then wrote about the whole arc — including the part where my first fix was also slightly wrong. That post was more useful, and more honest, than the reactive version would have been.

The Time I Shared Too Early

The clearest mistake I've made here was sharing a "shipped" update for a feature that wasn't actually done — it worked, technically, but I hadn't tested it against a case that turned out to matter, and I found the problem two days after posting about it. Nobody called it out publicly, which somehow made it worse. I had to quietly fix it and never mention that the original post had been wrong, which meant the public record of what happened didn't match what actually happened.

The lesson wasn't "don't share unfinished work." Building in public is supposed to include the unfinished parts. The lesson was to be precise about what state something is actually in — "I built this and I'm testing it" reads just as honestly as "I shipped this," and it doesn't leave me quietly correcting the record later. I'm more careful now about the verb I use, not about whether I post at all.

The Filter I Use Now

Before I post an update, I ask one question: would I be comfortable if this exact post were the only thing someone ever read about this decision, with no follow-up and no correction? If the answer is no — if I'm relying on a future post to add nuance, walk something back, or explain a number I haven't fully understood yet — I wait. Not indefinitely, just until the post can stand on its own.

That filter has cut down on a lot of posts I would have written on instinct, and it hasn't made the public record less honest. If anything it's made it more honest, because what's out there now is closer to what I actually believed at the time, rather than a reaction I later had to quietly walk back.

The Actual Takeaway

Building in public doesn't mean narrating every thought as it happens. It means being honest about the things you do decide to share, and having a real reason — not just habit, and not just fear — for the things you don't. The client details stay out because the story isn't mine to tell. The exact numbers stay soft because a snapshot without context misleads more than it informs. The reversals wait until I understand them, because confusion narrated in real time isn't the same thing as transparency.

For more on the reasoning behind sharing progress, decisions, and setbacks openly, see more Building in Public posts.