Community articles

Building in Public When Nobody’s Watching

If you’re starting to build in public, share what you’re working on before you have an audience. Give people something specific to understand, try, or…

By Uriel Bitton · · 6 min read

Article cover

If you’re starting to build in public, share what you’re working on before you have an audience. Give people something specific to understand, try, or respond to. Then keep building and follow up.

That’s where I’d start.

I’m building Buildside in public, and my approach is pretty simple: share the journey and spend time talking to other builders. I want people to understand what I’m making while I’m still making it.

But when you’re starting, posting can feel awkward. You share a screenshot, explain your idea, check back later, and there’s barely a response.

It’s easy to take that personally. Or decide you need a better launch, a bigger feature, or something more impressive before posting again.

I wouldn’t wait for any of that. I’d make the next update easier for one relevant person to respond to.

Start with a problem someone recognizes

You don’t need to introduce yourself as an expert. You need to explain what you’re trying to solve.

“I’m building a SaaS” gives me almost nothing to work with. I don’t know who it helps or why I should follow along.

Here’s a made-up example of a more useful first post:

I’m building a booking tool for freelance photographers. I want clients to choose a time and pay a deposit without a long email thread. This week I’m working on the booking page. If you photograph events, I’d love to hear how you handle deposits now.

There’s enough context there for someone to join the conversation.

You’ve named the person, the problem, and the thing you’re doing next. You’ve also given them a question they can answer from their own experience.

You can write that before you have a finished product. You can write it before you have a product name.

Share a decision from the work you already did

image

I don’t think founders need another full-time job creating content about their startup.

You’re already making decisions. Some of those decisions are worth sharing.

For each update, try answering three things:

  • What did I change?

  • Why did I change it?

  • What am I checking next?

Using that same imaginary booking tool, an update could look like this:

I moved the deposit amount above the booking button. It was easy to miss lower down the page, and I want clients to see the cost before choosing a slot. Next I’m asking a few photographers to walk through it and tell me what’s unclear.

That gives me much more to respond to than “Big improvements coming.”

I can look at the page. I can disagree with the placement. I can point out something you missed.

You don’t have to turn every update into a lesson either. “I tried this and I’m still checking whether it helps” is a perfectly useful thing to say.

Keep a small note while you work. Write down decisions, things that confused you, and anything you changed your mind about. When it’s time to post, you’ll have something real to draw from.

Give people a small way to help

“Any feedback?” is a difficult request. Someone has to figure out what you’re building, inspect it, and decide which kind of feedback you want.

Make the request smaller.

Ask whether they understand the first screen. Ask which part of a setup flow feels unnecessary. Ask how they currently handle the problem.

If you share a screenshot, include what you want someone to look at. If you share a link, explain what they can try and roughly how long it takes.

I’d rather have one person carefully try a booking flow than collect a bunch of “looks great” replies.

With Buildside, founder feedback has helped me sharpen the product. That’s the kind of exchange I’m looking for when I share an update.

And when someone helps, follow up. Tell them what you changed or why you chose another direction. That gives the conversation somewhere to go.

Spend time with other founders

image

My approach includes talking to people throughout the day. That part matters to me as much as sharing my own updates.

If you’re just starting, find a few founders whose work interests you. Read what they’re actually saying. Try something they’ve shipped. Offer a specific observation when you have one.

A short “congrats man” is fine when someone hits a milestone. Every reply doesn’t need to become an essay.

But there’s also room to be useful. If their signup page confused you, explain where. If they’re working through a problem you recognize, share what you tried.

Keep your replies about their work. Let people get to know you through an actual conversation.

That’s the kind of interaction I want more of on Buildside.

Try a simple first week

If you’re unsure how to begin, I’d give yourself a small plan:

  1. Introduce the project. Say who it’s for, what problem you’re working on, and what you’re building this week.

  2. Show one piece of progress. Share a screenshot, rough demo, or decision. Explain why it matters to the person using it.

  3. Ask for one useful input. Give someone a specific question or a small thing to try.

  4. Post a follow-up. Explain what you learned, what changed, and what you’re doing next.

Spread those updates across the week. Between them, spend a little time reading and responding to other builders.

I’d keep the writing short enough that it fits around the actual work. A screenshot and a few clear sentences can be enough.

If nothing interesting happened that day, keep working. You don’t owe the internet a manufactured breakthrough every evening.

Look past the like count, but pay attention to the silence

image

I wouldn’t judge the first week by likes alone.

I’d also look at whether anyone understood the problem, tried the product, described their current workaround, or gave me a useful objection.

Keep a note of those conversations. They can help you decide what to test next.

But I also wouldn’t tell you to post the same thing forever and trust that an audience will appear.

If your updates keep getting no response, change something. Make the problem clearer. Show the product working. Ask a smaller question. Spend time where the people with that problem already talk.

And speak directly with potential users. Posting publicly can give those conversations context, but you still need to have them.

Other founders can help you improve how you build and explain something. You also need feedback from the people you hope will use it.

Make your next post useful to one person

I’m building Buildside around founders sharing their products, progress, and lessons. That includes the early work, when there’s still plenty to figure out.

You’re allowed to show something unfinished and explain what you’re trying to improve. You’re allowed to change direction after someone points out a problem.

For your next post, pick one thing you worked on today. Show it, explain one decision, and give someone a small way to respond.

Then get back to building. When you learn something, share the follow-up.

That’s a good place to start, even when it feels like nobody’s watching.