Build in Public Content Ideas: 26 From Your Normal Dev Work

"I have nothing to post today" is almost always false. Most developers underrate how much of their normal week is content — it just does not feel like content because it feels like work. Below are concrete ideas grouped by where they come from in your day, each one something you can post in under ten minutes using work you already did.

From shipping and commits

1. The specific bug you fixed today and who it affected.
2. A feature that went from idea to shipped in one day.
3. A before/after screenshot of a UI change.
4. A performance number that improved (load time, query time) with the actual figures.
5. A dependency you removed and why, with the size or complexity saved.
6. The commit stat card for the day — count, streak, one-line summary.
7. A feature you shipped that a specific user requested, credited to them if they are comfortable being named.

From decisions and tradeoffs

8. Why you picked one library or approach over another, with the real tradeoff, not a sales pitch.
9. A decision you reversed, and what you learned that changed your mind.
10. A scope cut — a feature you deliberately did not build yet, and why.
11. A pricing or plan change and the reasoning behind it.
12. An architecture choice explained in plain language for non-engineers following along.

From mistakes and postmortems

13. A bug that made it to production, what broke, and how you caught it.
14. A short postmortem: what happened, root cause, the fix, and what you changed to prevent it recurring.
15. An estimate that was wrong, and the real time something took.
16. A feature you shipped and then removed because it did not work as intended.

From users and feedback

17. A piece of user feedback that changed your roadmap, quoted with permission.
18. A support conversation that revealed a confusing part of the product, now fixed.
19. A milestone number — first user, tenth user, first paying customer, first churned customer and what you learned from it.
20. A feature request you declined, and the reasoning, shared respectfully.
21. A screen recording of a real user flow, start to finish.

From the business side

22. A revenue or signup number you are comfortable sharing, with context on what drove it.
23. A channel that did not work, and what you tried instead.
24. Time spent on marketing versus building in a given week, and how you are adjusting.
25. A tool or workflow change that saved you real hours.
26. An honest "what I'd do differently" note at a monthly or quarterly mark.

Turning a single idea into three posts

Most of the ideas above can produce more than one post without repeating yourself. Take "fixed a bug":

• Same-day post: one line on what broke and that it is fixed now.
• Follow-up post: the root cause, once you actually understand it.
• Monthly recap mention: group it with other reliability work into a short "what got more stable this month" note.

This turns one afternoon of work into content across a week without inventing anything — each post is a different, real angle on the same event.

A lightweight capture habit

Keep a running note — a text file or a single doc — titled something like "ship notes." After anything from the lists above happens, add one line the same day while it is still fresh. Twice a week, turn a few lines into actual posts. This closes the biggest gap in build-in-public habits: not lack of material, but forgetting the material happened by the time you sit down to write.

For the cadence and tone that keeps this sustainable long term, see how to build in public as an indie hacker. For turning the same material into search-indexed pages, not just social posts, see turning GitHub commits into blog posts.

Formats worth rotating, not just topics

Beyond what to post about, vary how you post it so the same type of update does not feel repetitive to regular readers:

• A short caption with a screenshot — the default and usually the fastest to produce.
• A stat card — commit count, streak, or a single number that shows momentum at a glance.
• A short screen recording — best for anything visual or interactive, like a new flow.
• A thread — reserve this for ideas with real depth, like a postmortem or an architecture decision, not for routine updates.
• A longer article — for the ideas above that keep coming up as questions, worth a durable, search-indexed answer instead of a one-off post.

Where gittomarket fits

The commit-driven ideas early in this list — the daily shipping summary, the stat card, the streak — are the ones gittomarket automates directly. Connect a GitHub repo once, and on shipping days it auto-renders a designed commit stat card and posts it to X, with LinkedIn and Bluesky cross-posts, using AI captions written for the builder's customers instead of a raw commit list. Approval runs through Telegram — tap to approve, or ignore and it posts automatically.

The same shipping day writes an auto blog article from the commits and keeps a public build page live at /w/<slug> with waitlist capture and a dofollow backlink, so the daily material from this list has a permanent home, not just a feed post. Free plans include 10 auto-posts a month and a build page from day one; the founding plan is $9/month for the first 20 spots before the price steps up. The decision, mistake, user-feedback, and business-side ideas above still take a human — automation covers the commit layer, not the reflection layer. A live example is gittomarket's own build page.