build-in-public

Building in Public on LinkedIn as a Developer — A No-BS Guide

Brad ·

There’s a version of “building in public” that actually works. You ship stuff, you talk about what you shipped, people find it interesting, some of them become users or collaborators or friends. It compounds over time.

Then there’s the version that makes everyone’s eyes glaze over. Vague platitudes about “the grind.” Screenshots of empty dashboards. Performative vulnerability that reads like a LinkedIn Mad Lib.

This post is about doing the first thing and avoiding the second.

What Building in Public Actually Means

Building in public means sharing the real process of making something — the decisions, the tradeoffs, the wins, and the stuff that went sideways. That’s it. It’s not a content strategy. It’s not a growth hack. It’s just… being transparent about your work.

The good version looks like:

  • “We switched from REST to tRPC this week. Here’s what broke and what got way better.”
  • “Hit 500 users. 80% of them came from one Reddit comment. Here’s the comment.”
  • “I spent 3 days debugging a race condition in our webhook handler. The fix was two lines.”

The bad version looks like:

  • “Day 34 of my startup journey. Feeling grateful.”
  • “Entrepreneurs, remember: the only failure is not trying.”
  • “Excited to announce that we’re working on something big. Stay tuned.”

See the difference? One has information. The other has vibes. People follow you for information.

Why LinkedIn Is Underrated for This

Most devs default to X (Twitter) for build-in-public content. And yeah, X has the indie hacker crowd. But LinkedIn has some underappreciated advantages:

The algorithm actually shows your stuff to people

LinkedIn’s organic reach is still absurdly good compared to other platforms. A post with decent engagement can easily reach 5-10x your follower count. On X, you’re shouting into a timeline that moves at light speed. On LinkedIn, your post sits in someone’s feed for hours.

Your audience has money

This sounds blunt, but it matters. LinkedIn users skew toward decision-makers, hiring managers, and people with budgets. If you’re building a dev tool, a SaaS product, or freelancing — these are the people you want seeing your work.

Less noise in the developer niche

The developer build-in-public space on LinkedIn is way less crowded than X. You’re not competing with thousands of “just shipped day 47” threads. There’s room to stand out by just being specific and useful.

Posts have a longer shelf life

A tweet has a half-life of about 18 minutes. A LinkedIn post can generate engagement for days. That’s a better return on the 15 minutes you spent writing it.

What to Actually Share

Here’s the stuff that gets real engagement and builds a real audience. The common thread: specificity.

Milestones with context

Don’t just say “we hit 1,000 users.” Say how long it took, what the growth curve looked like, what channel drove it. Numbers without context are just bragging. Numbers with context are interesting.

Decisions and tradeoffs

“We chose Convex over Supabase for our backend. Here’s why.” Technical decisions are gold for build-in-public content because they’re inherently opinionated, and opinions drive engagement. Just make sure you explain your reasoning — “it’s better” is not a reason.

Failures and what you learned

Real ones. “Our launch flopped because we posted at 11pm on a Friday and our landing page had no clear CTA” is useful. “Sometimes things don’t go as planned, and that’s okay” is a greeting card.

Actual numbers

Revenue, user counts, conversion rates, churn, costs. Developers are data people. Give them data. You don’t have to share everything, but sharing something real builds trust fast.

Tools and stack decisions

Posts about your tech stack consistently perform well. People are always evaluating tools. If you write a genuine take on why you chose something — and especially if you include what you tried and rejected — that’s genuinely useful content. Check out our developer LinkedIn post examples for templates that work well for these kinds of posts.

What Not to Share

Vague motivation posts

“Keep going. You’re closer than you think.” Unless you’re a fortune cookie, skip this.

”Day X” posts with no substance

Streaks are fine as a personal discipline tool. But “Day 47: worked on the landing page” gives your audience nothing. If you’re going to do a streak, each post needs to stand on its own with something specific and interesting.

Humble brags disguised as lessons

“I can’t believe we went from 0 to $50K MRR in 3 months. I guess the lesson is to just keep shipping!” We can all see through this. If you want to share a win, just share the win. Own it. Don’t pretend it’s a lesson.

Anything you’d be embarrassed to say to a developer friend over coffee

Good litmus test. If it sounds weird coming out of your mouth in a real conversation, it’s going to sound weird on LinkedIn too.

Frequency and Consistency

2-3 times per week is the sweet spot

Daily posting leads to burnout, and your content quality drops fast when you’re scraping for topics. Two to three posts per week is sustainable long-term and gives each post room to breathe in the algorithm.

Batch your writing

Spend 30-45 minutes once a week writing your posts for the next few days. You’ll write better when you’re in “writing mode” than when you’re context-switching from code at 5pm trying to think of something to say.

Consistency beats frequency

Posting twice a week for six months beats posting daily for three weeks and then going silent. LinkedIn rewards accounts that show up regularly. Pick a frequency you can actually maintain.

How to Get Your First Engagement

Starting from zero followers is the hardest part. Here’s how to break through.

Comment on other people’s posts first

Find 5-10 developers or builders in your space and leave genuine, thoughtful comments on their posts. Not “Great post!” — actual responses that add something. “We ran into the same issue with Vercel cold starts. Switching to streaming responses cut our TTFB by 60%.” Be specific, be useful. People will check your profile.

Ask real questions

“We’re debating between Stripe and Lemon Squeezy for our payment stack. Anyone switched from one to the other? What sucked?” Real questions get real answers and drive engagement. LinkedIn loves comments.

Tag people, but only when it’s genuine

If you’re writing about a decision and someone’s blog post influenced it, tag them. If you’re using someone’s open source tool, tag the maintainer. Don’t tag random influencers hoping for a retweet.

Cross-post from your actual work

This is the easiest one. You already merged PRs this week. You already made technical decisions. You already have opinions about the code you wrote. You just need to turn that into a post. If you’re working from GitHub, you can turn your PRs directly into LinkedIn posts without starting from a blank page.

Tools That Help

Building in public shouldn’t feel like a second job. The best setup is one where your content comes from work you’re already doing.

Use your git history as a content source

Your merged PRs are a goldmine of build-in-public content. Each one represents a decision, a feature, a fix — something worth talking about. The problem is translating a PR description into something that reads well on LinkedIn. That’s where ShipPost comes in — it connects to your GitHub, scans your merged PRs, and generates human-sounding LinkedIn posts from your actual shipping activity. No blank page, no “what should I write about today.”

You can see exactly how the PR-to-post workflow works — it pulls in the PR title, description, and diff context, then generates multiple variations you can edit and post.

Keep a running notes doc

Not everything needs to be a polished post. Keep a doc where you jot down interesting things that happen during your workday. “Weird bug in Safari,” “finally figured out the caching issue,” “users keep asking for dark mode.” When it’s time to write, you have a list of topics ready.

Screenshot everything

Screenshots of dashboards, terminal output, before/after UIs, error messages — these all make great post visuals. Get in the habit of hitting Cmd+Shift+4 when something interesting happens.

The Compound Effect

Here’s the thing about building in public that most people don’t stick around long enough to see: it compounds. Your first month, maybe 10 people see each post. By month three, it’s 100. By month six, people start recognizing your name. By month twelve, inbound opportunities show up — users, job offers, collaborators, conference invites.

But only if you’re sharing real stuff. The “thought leaders” who post recycled advice plateau fast because there’s nothing underneath the content. When you’re sharing your actual building process, every post has depth because it comes from real work.

Start this week. Pick one thing you shipped or decided or learned, write 150 words about it, and post it. That’s it. You can figure out the rest as you go.

Ready to turn your GitHub activity into LinkedIn content? Get started with ShipPost and skip the blank page entirely.

Want to turn your shipping history into LinkedIn posts that actually sound like you?

Try ShipPost free

No credit card. No subscription. Bring your own API key.