Devlogs are short updates you post about your project, tied to time you've actually spent on it. They serve three purposes — and only one of them is "Stardance requires it."
- They prove you spent the time you logged. Reviewers and voters can see your progress wasn't fabricated.
- They give voters something to scroll through when judging "storytelling" — one of the four scoring axes.
- They help your future self remember what you were doing, which makes coming back after a break much easier.
Devlogs that get noticed do all three. The ones that don't usually fail at #2.
What a great devlog looks like
Imagine someone scrolling through Explore. They have 30 seconds. What makes them stop on yours?
1. Show, don't tell
At least one image, GIF, or short video, every devlog. The single biggest predictor of a devlog getting attention is whether it has visual content.
You don't need polish — you need something to look at:
- Screenshot of the new feature working (or hilariously not working).
- Animated GIF of the UI flow you just built.
- 30-second screen recording — works for almost any project type.
- Photo of the hardware you assembled, half-soldered.
- Diagram you sketched on paper.
2. Lead with what changed
First sentence: what's new since last time. Don't bury it.
Good: Added drag-to-reorder for the playlist. The hard part was making it work on touch — I thought I could reuse the mouse handlers but the gesture system on Android needed completely different events.
Bad: Today I worked on my project for a few hours. I made some progress and learned a lot.
The bad version doesn't tell a reader anything. The good version makes them curious about what an Android gesture system looks like.
3. Include the friction
Voters score "storytelling" higher when they get a sense of struggle and resolution. The devlog where you spent four hours and only got the icon to render correctly is more interesting than the one where everything worked the first time.
You don't need to be theatrical. Just be honest:
Spent two hours fighting Tailwind v4's new theme syntax before realizing my layer ordering was wrong. Whole afternoon, two characters changed.
4. Keep it short
3–6 sentences plus an image is the sweet spot. Devlogs aren't blog posts — aim for something a voter will actually read in 15 seconds.
How often to post
After every meaningful chunk of work. "Meaningful" is up to you, but a useful rule:
You need at least one devlog since your last ship to ship again. Don't go too long without posting one — devlogs are how voters and reviewers see that your progress is real.
Most projects end up with one devlog every 2–4 hours of work. That's a good cadence. Less than that and you'll drift; more than that and they get thin.
What to write about
If you don't know what to write, here are reliable angles:
- What you built. The default. Show the new feature.
- What broke. Bugs you hit, especially the embarrassing or weird ones. These get the most engagement.
- What you learned. A new library, a concept you'd never used before, a mistake you don't want to repeat.
- A decision you made. Why you chose X over Y. Voters love this — it shows technical thinking.
- Something that surprised you. A perf improvement that came from nowhere, a user reaction you didn't expect.
- Aesthetic / design decisions. If your project has a visual identity, talk about it.
The devlog you should not post
Devlogs that say "made progress, will update later" don't help anyone. If you're between meaningful chunks, just keep working — there's no quota. Only post when there's something to show.
One workflow that works
Take screenshots and short clips while you're working. When you finish a chunk and stop coding, you'll already have the visual content waiting. Writing the text takes 5 minutes when the work is fresh.
Trying to reconstruct a devlog three days later, when you've forgotten what you did and don't have screenshots? That's how devlogs get skipped.