← All articles

Building & community

What happened to the "build in public" part?

I want to connect with people making things. "Build in public" sounds like an invitation, but I often can't find much of the work.

Join the discussion →
Spite peers through a workshop window crowded with announcement flyers to see an unfinished mechanical project on the workbench inside.

I like knowing people who are making things. I'm interested in what they're trying and where it's getting difficult. Someone changing their mind about a feature can give me more to think about than the finished product announcement.

That's what interests me when someone says they're building in public. I take it as an invitation to see enough of the process that we might have something worth talking about.

Lately, though, I keep making connections without learning much about what anyone is building. There are plenty of people using the phrase. I'm having a harder time finding the part it promises.

I'd like to get past knowing that we're both builders. An introduction tells me we might have something in common. If that's as far as the exchange goes, I've gained another contact and almost nothing to talk to them about.

I don't need somebody to impress me. An unfinished project can be interesting. A small tool can be interesting. Tell me why the obvious approach didn't work and there's probably a conversation in it. I'd happily take that over another general discussion about the importance of connecting.

Give me something I can ask about

Imagine someone showing a change to their signup process. A screenshot tells me what it looks like. Knowing that people kept abandoning the second step, what the builder changed, and whether it helped gives me something to ask about. Maybe I've misunderstood the same problem. Maybe their fix would fail for my users, and working out why would teach us both something.

That example doesn't require a dramatic failure, a revenue milestone or a public confession. It requires a little context. The same goes for a game mechanic that looked good on paper and felt tedious when somebody played it. What made it tedious? What did you try next?

Even an unresolved problem is useful. I'd rather hear that you're still stuck than have every difficulty arrive already packaged with a triumphant lesson. Sometimes the lesson is that the first three fixes were also shit. That seems like a perfectly reasonable stage at which to talk to another person.

A launch announcement has its place. So does being pleased that something finally works. But if I only see the finished announcement, there's less room to take part. I can congratulate you. I might try the product. I still haven't learned much about how you got there.

Those details are how I'd get to know your work. If I know you've spent a week trying to get a feature working, I can appreciate why you're pleased with a change that looks minor. If you explain why you scrapped it instead, I might save myself the same week. That's a useful exchange even if neither of us ever buys anything from the other.

The update can start making the decisions

There's a reason this can drift. A person trying to share their work also has to decide what is worth publishing. Some parts are easy to show. Others take a week and leave almost nothing that looks different.

In an August 2026 essay, Yuzheng Sun, an advocate of building in public, described the risk of attention starting to direct the work itself. Projects and updates can be chosen for how well they will travel, while less visible work gets squeezed out. Yuzheng Sun on building in public

Consider a builder choosing between making a demo look better and fixing a recovery process that only matters when something breaks. The demo improvement is easier to explain to a passing audience. The recovery work might matter much more to the person whose data would otherwise disappear. If publishing regularly starts deciding which job gets done, the people watching have acquired a surprising amount of control over the product.

And the routine work can be interesting if somebody explains what was at stake. Why was recovery unreliable? What assumption caused it? You don't have to show customer data to explain a mistake. You also don't have to turn it into an inspirational account of how losing an afternoon made you a better entrepreneur.

I'm interested in enough of the work to understand a decision. I don't need a character-development arc every time you fix a form.

There is a cost on the reader's side, too. If an update gives me nothing specific to respond to, a generic reply is the easiest thing to offer back. Repeat that often enough and we can spend a lot of time acknowledging each other without ever having a decent conversation. Everyone has participated. I'm not sure anyone knows the other person much better.

You can keep the private parts private

None of this means somebody owes me their accounts, customer list or source code. Wanting to connect isn't a request for access to their internal systems.

There are good reasons to be selective. In April 2026, Arvid Kahl, who credits public sharing with helping his earlier business, argued that cheaper AI-assisted copying makes detailed disclosure riskier. He now favors sharing experiences and lessons while withholding information that would help someone reproduce the business. Arvid Kahl, The Increasing Risk of Building in Public

I can respect that boundary. You can explain why you dropped a feature without handing over the implementation. You can describe a support problem without identifying the customer. You can also say that you can't discuss something yet. I'd understand that more readily than being offered a vague lesson where the interesting part ought to be.

For a more extensive version of openness, Buffer still maintains public business metrics, including customer churn, alongside its revenue figures. That's one concrete example of making information available for people to examine. It isn't a disclosure checklist that every person with a side project has to satisfy. Buffer's public metrics

I'm also not going to pretend there was a time when public building had no promotional purpose. Being visible can help people find your work. Explaining a product can help sell it. Someone can be marketing it and still give the rest of us something useful.

What disappoints me is the gap between an invitation to see the work and how little I sometimes come away knowing. I can't tell from that gap whether someone is working quietly, protecting a business, unsure what to share, or concentrating on promotion. It does tell me that the connection hasn't led to the conversation I was hoping for.

I should apply the same standard to what I put out. If I say we're trying something at Club Spite, giving people a result worth looking at, or a decision they can question, would make that invitation mean more. That includes coming back to explain a change of direction or an idea that turned out to be less interesting than we'd hoped. It doesn't require publishing a daily report.

There are people doing this well, and I want to find more of them. I don't mind if the project is early or the update is rough. Tell me what you're trying to work out. Show enough that I can ask a question about it. I'd like our next conversation to get further than finding out that we both build things.

The club has thoughts.

Been there? See it differently? Add your perspective.

Loading the discussion...