What to post on X when you have no ideas (a list for developers)
By Naod Tadele · · 5 min read
It's Tuesday. You've been heads down for three days. You open X, stare at the empty box, and think: I have nothing to say.
That's rarely true. What you have is work that doesn't feel like news. Developers tend to wait for a launch before posting, and launches are rare. The posts that build an audience are the small, regular ones. This guide gives you eight places to find them.
Why "no ideas" usually means "no filter"
You don't lack material. You are filtering too hard. Somewhere in your head is a rule like "only post big wins." So a fixed bug, a decision you argued over, or a weird error all get thrown away.
Loosen the rule. A post doesn't have to be impressive. It has to be specific and true. A reader who follows a developer building in public wants the texture of the work, not just the highlights.
Eight sources of posts
1. Your last five commits
Open your git log. Each commit is a small thing you changed for a reason. Pick the one with the best reason and say it plainly.
Spent the morning on one bug: the nightly summary sent twice when two alerts closed in the same minute. Fix was four lines. Finding it took four hours.
2. A decision you made
Choosing between two options is a story. State both, say which you chose, and say why.
Nightshift summaries: send them when the incident closes, or when the on-call engineer asks? Went with when it closes. People forget to ask.
3. Something that went wrong
Failures get more replies than wins, because people recognize them. Say what broke and what you changed.
4. A question from a user
A support message or a feature request is a post. Remove the name, keep the question, and say what you'll do about it.
5. A number you can share
Signups, sessions, an open rate, a page speed. A small number is still a number. If you share revenue, see how to write a monthly revenue update post.
6. A tool or trick you learned this week
A shell alias, a Postgres query, a setting that saved you an hour. Show the snippet.
git log --since="1 week ago" --oneline --author="$(git config user.name)"The one command I run on Fridays to remember what I did this week. Most of my post ideas come from its output.
7. A thing you changed your mind about
"I used to think X. Now I think Y." These are easy to write because you already did the thinking.
8. What you're about to do
A plan is a post. It creates a small promise, and gives you a follow up post later.
Tomorrow: moving Nightshift's alert parsing out of one giant function. Will report back on how bad it is.
A simple rule for quiet weeks
When you're stuck, run through three questions:
- What did I change this week, and why?
- What surprised me?
- What did someone ask me?
One honest answer to any of them is enough for a post. Write it in your own words, keep it short, and post it.
Keep a running list
The real fix is to stop searching for ideas on the day you post. Keep a note, and drop one line into it whenever something happens: a bug, an odd decision, a message. When you sit down to post, you pick from a list instead of facing a blank box.
What not to do
- Don't post filler. "Working hard today!" tells people nothing.
- Don't wait for something big. Small and regular beats big and rare.
- Don't copy someone else's post. Borrow the shape, not the words.
How Loudcode helps
Loudcode is built for the quiet weeks. It reads your GitHub commits, pull requests and releases, plus revenue from Stripe, Polar or RevenueCat, and drafts posts for X in your voice. When there isn't much to draft from, its Ideas feature suggests angles from your product, revenue and repo. A weekly 30 second check-in plans the week's posts. You review every draft, and nothing is posted until you approve it. For more angles, see the build in public post ideas.