Loudcode

30 build in public post ideas for weeks you think you have nothing

By Naod Tadele · · 7 min read

A notebook with "Write ideas" on a wooden desk
Photo by Aaron Burden on Unsplash

The hardest week to post is the one where nothing big happened. No launch, no milestone, just a lot of small fixes and a vague sense that you should say something. So you say nothing, and a quiet week turns into a quiet month.

Here's the thing: your followers don't need a launch every week. They need to see that you're still building, what you're learning and where you're going. Almost every week has material for that. You just have to know where to look.

Below are 30 ideas, grouped by the kind of post they make. Pick two or three for this week.

Things you shipped (even small ones)

  1. One feature, explained from the user's side. Not "added filters" but "you can now find last week's invoices in two clicks".
  2. A before and after. Two screenshots of the same screen, a month apart.
  3. The tiny fix someone asked for. Mention that a user asked. It shows you listen.
  4. Something you deleted. Removing a feature is a decision worth explaining.
  5. A speed improvement. "The dashboard loads in under a second now" is concrete and easy to care about.
  6. A bundle of small things. Three small changes, one sentence each, as one post. See how to turn commits into posts.
Example post
Small week, but three things got better: - Search now matches typos - Exports keep your column order - The mobile menu finally closes when you tap outside None of these would make a launch post. All of them came from user emails.

Things you learned

  1. A mistake and what it cost. Be specific: the hours, the users, the money.
  2. A belief you changed. "I thought X. Then Y happened. Now I think Z."
  3. A tool you switched to or away from, and why.
  4. Something a user taught you about how they actually use the product.
  5. A decision you almost made. The road not taken is often more interesting than the road taken.
  6. What you'd tell yourself on day one.

Numbers

  1. A milestone: first user, first sale, 100 signups. Use the exact number.
  2. A number that went the wrong way, and what you think caused it.
  3. Your weekly numbers, even when they're small. Consistency makes small numbers interesting over time.
  4. A cost breakdown: what it costs to run your product each month.
  5. Time spent: how many hours a feature actually took versus your estimate.

If you're unsure how much revenue to share, read how to share your MRR publicly.

Behind the scenes

  1. Your setup: editor, stack, the one tool you'd keep if you had to drop everything else.
  2. A normal day, hour by hour. It's more interesting to people doing the same than you'd think.
  3. Your to-do list for the week, posted on Monday.
  4. How you test a feature before shipping.
  5. A rough sketch or wireframe of something you haven't built yet.
  6. Where your first users came from.

Questions

  1. Which of two features should you build next? Offer exactly two options.
  2. Ask how people currently solve the problem your product solves.
  3. Ask for a roast of your landing page or onboarding.
  4. Ask what a price should be. People have opinions about pricing.
Example post
Building the next feature for Nightshift and can't decide: A) Slack threads for each incident B) A weekly email summary Which would you actually use?

Recaps

  1. The week in five bullet points. Use the weekly update template.
  2. The month in numbers.
  3. What didn't get done, and why. Honest recaps build more trust than perfect ones.

How to use this list

Don't post all of these in one week. A good week has three to five posts, one a day at most, and a mix of types: something you shipped, something you learned, and a question. If you want the reasoning behind that mix, the build in public guide covers it in depth.

The ideas are the easy part. The hard part is noticing them while you're busy building. That's why I built Loudcode: it reads your GitHub and a 30-second weekly check-in and turns them into a week of posts in exactly this mix, for you to edit and schedule.

You ship the code. We write the posts.

Your commits, revenue, traffic and a 30-second weekly check-in become build-in-public posts for X, in your voice. You approve every post.

Start your free trialTry the live demo

Keep reading

How to turn GitHub commits into posts people actually read"fix: handle null in auth middleware" is a great commit and a terrible post. Here's the translation.How to share your MRR publicly (and when not to)Revenue posts are the most-read posts in build in public. They're also the easiest to get wrong.A weekly build in public update template you can copyOne template, filled in every Friday, is the simplest build in public habit that actually sticks.