Build in public mistakes that cost founders followers (and what to do instead)
By Naod Tadele · · 6 min read
Building in public sounds simple: share what you build, and people who care will follow along. Then a few months in, the posts get fewer replies, the follower count stalls, and it feels like nobody is listening.
Usually it's not the idea of building in public that failed. It's a handful of habits that make posts easy to scroll past or, worse, easy to unfollow. Here are the most common ones and what to do instead.
1. Posting only when something big happens
Many founders post on launch day, go quiet for a month, then come back with another launch. Followers forget who you are in between, and the algorithm has no recent signal that your account is worth showing.
Instead: post small, real updates between the big ones. A bug you fixed, a decision you made, a customer question that changed your roadmap. Consistency matters more than size. If you're unsure how often, how often to post when building in public covers a pace that's easy to keep.
2. Writing changelogs instead of stories
"Shipped v1.4.2: fixed pagination, updated deps, improved perf" is useful in a changelog. On X it reads like noise, because nobody outside your team knows why it matters.
Instead: pick one change and say who it helps and why.
Weak:
Nightshift v1.4 is out. Fixed alert grouping, new Slack integration, perf improvements.
Better:
On-call engineers kept getting 6 incidents for one bad deploy. Nightshift now groups alerts by the last change before they fired. Last night that turned 40 alerts into 1 incident.
Same release. One gives people a reason to care.
3. Only sharing wins
A feed of nothing but milestones starts to feel like an ad. It's also less interesting. People follow builders to see how things actually go, including the parts that don't work.
Instead: share the wrong guess, the feature nobody used, the week you rewrote something twice. Keep it honest without turning it into a complaint. A good failure post ends with what you learned or what you'll try next.
Spent the week building a Nightshift dashboard nobody asked for. 3 people opened it. Lesson: ask the 10 most active users before building, not after.
4. Sounding like a press release
"We're thrilled to announce" and "excited to share" signal marketing copy, and people tune it out. The same goes for AI drafts that sound like every other AI draft.
Instead: write the way you'd explain it to a friend who codes. Short sentences. Specific nouns. Your own phrases. If a post could have been written by any company, rewrite it until it could only come from you.
5. Dropping a link in every post
When every post ends in "check it out" with a link, followers learn that your posts are asks, not value. Many people also find that posts with links get less reach than posts without them, so the habit can hurt twice.
Instead: make most posts useful on their own. Save links for the posts where the link is the point, like a launch or a write-up. Or put the link in a reply.
6. Bragging about revenue without context
Revenue posts can be some of the most interesting things a founder shares. They can also come across as showing off, especially when they're just a big number and a rocket.
Instead: pair the number with what caused it and what you learned. Context turns a brag into a lesson.
Nightshift crossed $2k MRR this month. Almost all of the growth came from one change: a free tier for teams of 3 or fewer. Small teams tried it, then brought it to bigger ones.
The guide on sharing MRR publicly goes deeper on when to share and when not to.
7. Never replying to anyone
Building in public is a conversation. If you post and leave, people stop replying because nobody answers. Your account starts to feel like a broadcast.
Instead: set aside a little time after each post to reply. Reply to other builders in your space too, with something real to add, not "great post." Many of the people who end up following you will find you in someone else's replies.
8. Chasing growth hacks instead of building
Engagement bait, "like if you agree" posts, and borrowed viral formats can get a spike. They rarely bring the people you want: developers who would use your product or follow your work for the long run.
Instead: let the product be the content. What you shipped, why, and what happened next is a story only you can tell. That's the advantage of building in public, so use it.
9. Quitting before it compounds
Most of these mistakes come from the same place: building in public feels slow at first, so people either stop or start reaching for shortcuts. The early weeks often feel like posting into an empty room.
Instead: treat it like shipping. Small, regular updates that build on each other. Keep a running list of things worth posting during the week so you never start from a blank page. If you need prompts for quiet weeks, try these build in public post ideas.
A quick checklist before you post
- Does this post say who it helps or why it matters?
- Would it make sense to someone who has never heard of your product?
- Does it sound like you, not a press release?
- If there's a link, is the link the point?
- Will you be around to reply?
If the answer to all five is yes, post it.
How Loudcode helps
The hardest parts of avoiding these mistakes are staying consistent and remembering the story behind each change. Loudcode reads your GitHub commits, pull requests and releases, plus revenue and traffic if you connect them, and drafts posts in your voice from what you actually shipped. A weekly 30-second check-in plans the week, Ideas fills in the quiet weeks, and every post waits for your approval before it goes to X.