Hot take: most "building in public" is performance art.

I know this will annoy people. The building-in-public movement has genuine believers, thoughtful practitioners, and a real philosophical argument behind it. Transparency, accountability, community feedback, all of it. I respect the intent. I just think the practice, as it actually plays out on social media, has become something very different from what it was supposed to be.

What building in public usually looks like: a carefully crafted tweet thread about the emotional journey of writing a landing page. A screenshot of a terminal with a caption about "the grind." A time-lapse video of a code editor, scored to lo-fi beats, showing two hours compressed into thirty seconds. Revenue screenshots. MRR updates. "Lessons learned" threads that are really just engagement farming dressed up as vulnerability.

What actually building looks like: three hours at the kitchen table after the kid is in bed, swearing quietly at a deployment error. Closing the laptop at midnight because you're too tired to see straight. Opening it again at 6am because you had an idea in the shower. No audience. No content. No thread. Just the work.

The content-creation trap

The problem with building in public is that it turns the building process into content. And the moment something becomes content, it changes. You start making decisions not based on what's best for the product, but on what will make the best update. You choose the more dramatic problem over the more important one. You spend twenty minutes writing a tweet about a feature that took ten minutes to build. The ratio inverts. The documentation of the work starts consuming more energy than the work itself.

The moment building becomes content, it changes. You start making decisions based on what will make the best update, not what's best for the product. The documentation of the work starts consuming more energy than the work itself.

I've watched people spend more time creating build-in-public content than actually building. That's not a productivity system. That's a content strategy wearing the costume of a development methodology. And there's nothing wrong with having a content strategy -- just don't pretend it's something it isn't.

The 9pm-to-midnight reality

My building sessions are unglamorous. They happen at night, after dinner, after bedtime stories, after the house goes quiet. They're messy. Full of wrong turns, deleted attempts, and fifteen-minute stretches where I stare at the screen trying to figure out why something that should work doesn't.

None of this is content. None of it would make a good tweet. The moments that produce the best work are the ones that look the worst from the outside -- the long, quiet stretches of focused effort where nothing photogenic happens but everything important does.

🎯
The real schedule: Kid to bed by 8. Start building by 9. Hit a wall by 10:30. Push through or give up, depending on the day. No live streams. No updates. Nobody watching. Just the work.

If I'd been building in public, those sessions would be different. I'd be thinking about what to share. Taking screenshots at interesting moments. Composing pithy observations about the process. And every minute spent doing that would be a minute not spent building. The trade-off is real, even if the building-in-public crowd pretends it isn't.

Ship the thing, then talk

My approach is the opposite: build in private, ship in public. Do the work where nobody's watching. Make the mistakes in silence. Take the wrong turns without an audience judging your sense of direction. Then, when the thing exists, when it's live and working and real, talk about it.

The product is the announcement. Not the journey. Not the process. Not the daily update. The finished, working, usable product is the thing that deserves attention. Everything else is preamble.

I built fourteen products before writing a single blog post about how I build. Fourteen live, working websites that people can visit and use. Not one of them was documented during the build process. Not one of them had a public journey. They were built in the quiet hours, shipped when they were ready, and only discussed after they existed.

I built fourteen products before writing a single blog post about any of them. The products spoke first. The writing came when it was ready. That order matters.

The honesty problem

Here's the other thing about building in public that nobody wants to say: it incentivises a very specific kind of dishonesty. Not outright lying, but curation. You share the wins. You share the "struggles" that have satisfying resolutions. You share the revenue milestones. You don't share the three projects you abandoned because they weren't working. You don't share the feature you spent a week on that turned out to be pointless. You don't share the days when you sat down to build and just... didn't.

Building in private is more honest, paradoxically, because there's no audience to perform for. Every decision is made for the right reason -- because it's what the product needs -- not because it'll make a good update. The work is purer when nobody's watching.

An exception, and a caveat

I'll grant one thing: writing about what you've learned after shipping is genuinely valuable. This blog exists because I believe in sharing what I've figured out. The difference is timing and intent. I'm not documenting the process to build an audience. I'm reflecting on what I've learned to help other people who might be building similar things. The work comes first. The writing comes after. That order matters.

Build in private. Ship in public. The product is the content. Everything else is commentary.