Where to Build in Public: X vs. IndieHackers vs. Your Personal Blog vs. ProductLog

5 min readLanguagesentr
Where to Build in Public: X vs. IndieHackers vs. Your Personal Blog vs. ProductLog

For a long time, building in public meant X.

It made sense. My network was there, the conversations were real-time, and posting an update took seconds. IndieHackers never pulled me the same way, if you're not building for makers, it can feel like the blind leading the blind: a room where everyone's there to trade ideas, network, and quietly promote to each other. I'd rather talk to my own audience. So X it was.

Then I noticed the thing X is quietly terrible at: keeping a record.

I'd post "working on this feature today." A week later it was gone, buried so deep that I forgot I'd ever written it. Worse: when someone replied "nice, but there's a bug right here," that feedback vanished too. No record of the update, no record of the response. The most valuable part of building in public - the trail of what you shipped and what people told you about it - was evaporating in real time.

The honest fix looked absurd: run a Featurebase-style tool for the structured feedback, plus X for reach, plus IndieHackers for the maker crowd. Three places, none of them talking to each other.

That's the moment ProductLog stopped being "another feedback tool" in my head and became the thing I actually needed: a public place whose entire job is build-in-public, where the record, the roadmap, and the feedback all sit on top of a community, instead of inside a private dashboard. I took the structured-feedback features you'd normally bolt on with a separate tool and put them where they belong for someone building in the open: around the maker, and around the people watching them build.

So if you're deciding where to build in public, here's the honest map. No paid tools in this comparison, just the free, organic homes makers actually use.

The axes that actually matter

  • Reach: will anyone see it?

  • A durable record: can you (and others) still find the update in a year?

  • Recorded feedback: when someone reports a bug or asks for a feature, does it persist and get structured?

  • Ownership: do you own the surface, or rent it?

  • Build-in-public fit: does it hold the daily update, the roadmap, and the feedback in one place?

The honest comparison

X / Twitter; wins reach, loses the record. Unbeatable for real-time reach and talking to your own network. But updates vanish, and so does the feedback under them. Great megaphone, terrible filing cabinet.

IndieHackers; wins the maker crowd, if that's your audience. A real community and a milestone format. But if you're not building for makers, it's the wrong discovery and it isn't a structured build-log you own.

A personal blog; wins ownership and durability. You own it, it's permanent, it ranks over time. But a full post every time you touch a feature is overkill, there's no built-in audience, and feedback lives in comments, if at all.

ProductLog; wins the integrated record, loses (for now) on reach. Updates, roadmap, and feedback in one place, with a permanent trail around one maker and one project. What it does not give you yet is discovery or a network. I'm in the cold-start phase, and I won't pretend otherwise.

So where should you build in public?

Match the tool to your actual goal:

  • If the goal is discovery, ProductHunt or IndieHackers will out-reach me today.

  • If the goal is talking to other makers, Reddit or IndieHackers are better rooms.

  • If your project is already public and you want the structured record + roadmap + feedback while you build in public, that's exactly what ProductLog is for, and it's free.

For most people the honest combo is: keep the reach where it already lives, and own the record somewhere built for it.

"Isn't this just a free Canny?"

Fair question and the answer is the whole point. Canny and Featurebase are private feedback boxes you bolt onto your own product, for your own logged-in users. They're tools. ProductLog is a public destination: makers build in the open, the stories are out here to be read, and other people are meant to show up. The roadmap and feedback aren't the product, they're a layer on top of a community. A feedback tool collects requests in private; ProductLog is where you build in public, in front of an audience that's supposed to grow. That audience is small today. I'm still in cold-start, but a community that's filling up is a fundamentally different thing from a private widget that was never meant to be a destination at all.

And here's the quiet proof: you're reading this on ProductLog. Not long ago there were no stories here, and no one to read them. The fact that this page reached you — that someone showed up to read what a maker is shipping — is the cold-start starting to thaw. A feedback tool doesn't do that. A community beginning to exist does.

The part I won't oversell

ProductLog is early. It probably doesn't match every feature of a dedicated, paid feedback tool yet. What it has instead: it's completely free, and it has a founder who's itching to build and just waiting on the feedback to tell him what's missing. As people use it, the gaps close. That's the bet and "build in public" means I'm making it out loud.

Bottom line

There's no universal best place to build in public. X wins reach, a blog wins ownership, IndieHackers wins the maker crowd — and each loses what the others win. I built ProductLog because the one thing none of them gave me was a durable, structured record of both the work and the feedback, in the same place I was already building in public. If that's the gap you feel too, it's worth a look. If your gap is raw reach or an audience that already exists, I'll point you to the better room myself.

Comments

No comments yet. Be the first to comment!

Sign in to leave a comment.