Devlogs: what they actually do for your game

Most devlog advice tells you to post consistently, be authentic, and film your screen. That's fine, and it's also the least useful part.

Here's what nobody mentions: a devlog isn't only a video. On Steam it's an event, and Valve documents exactly where those events appear — seven places, including the front page of the store. One of those placements is limited to five uses per game, ever. If you're going to spend the time writing devlogs at all, knowing that changes when you write them.

I'll go through what a devlog is, where it actually gets seen, the scarce resource nobody warns you about, and the honest answer to "will this get me wishlists." That last answer is less flattering than the guides suggest.

What a devlog is (and the naming confusion)

A devlog is a development log: a recurring post about what you're building, what broke, and what changed. It's an old format — programmers have kept them for decades — that indie game devs adopted because it does two jobs at once. It documents the development process, and it gives fans a reason to keep watching.

Small annoyance up front: searching "devlog" is a mess, because there's also a game called Devlog. If you're looking for advice and keep landing on a store page, that's why.

The format runs in three main places, and they are not interchangeable:

• Video devlogs — YouTube, usually 8–20 minutes, sometimes short clips.
• Written devlogs — your own site, itch.io's devlog feature, or a blog.
• Platform update posts — Steam events, which is the one that gets skipped.

Most people pick one. The interesting move is that the same work feeds all three, and only one of them is actually yours.

Where a devlog actually shows up on Steam

This is the part I'd read twice, because it's documented and specific, and almost nobody writing about devlogs mentions it.

Steam's event tools have three levels of update post: Patch Notes, Regular Updates, and Major Updates. A Major Update appears in seven places:

There's also a smaller effect worth knowing: update events refresh the "last updated" stamp on your store page. That's a quiet signal to anyone evaluating whether your game is alive.

To post a Major Update you need a title, a description with images, and an 800 × 450 cover image. A 1920 × 622 header is optional. Formatting is BBCode.

The easiest possible start

If a devlog habit sounds like a lot: when you push a new build through SteamPipe, Steam prompts you to write patch notes right there. Most developers use it for a bullet list of changes.

That's a devlog. A small one, but it's the same muscle, and it's the lowest-effort entry point that exists. Even a short list of fixed bugs, with a couple of screenshots, tells your customers you're still working on the game.

The scarce resource: five visibility rounds

Here's the thing I didn't know before researching this, and it changes how you should plan.

That "Recently Updated" spot on the Steam front page isn't automatic. It runs on Update Visibility Rounds, and Valve's rules are strict.

• Those five are shared between Early Access and full release. Spend them all during Early Access and you have none left for post-launch updates.
• It's shown to people who have your game in their library or on their wishlist. Not to strangers.
• Starting one requires a community announcement posted within the last 30 days. Your devlog post is that announcement.
• You can only start a round after your launch visibility has ended.
• Additional rounds may be granted to products that are selling well. May.

If that structure feels familiar, it should. It's the same shape as the one-Fest-per-game rule: a scarce, non-renewable thing you have to make a decision about, rather than a tap you turn on. Five rounds across the entire life of your game is not many. Save them for updates that genuinely deserve the front page.

Will a devlog get me wishlists?

Now the honest part.

I can't give you a number, and I'd be careful with anyone who does. When I went looking for data on devlog performance, the entire first page of results was marketing blogs quoting figures with no sample size, no time period, and no method — several of them published by companies selling marketing tools. I'm not repeating those here.

What I can tell you is what the mechanics imply, and the mechanics are clear enough.

Look at who Steam shows your update to. Library "What's New": people who own your game. News Hub: owners and followers. Recently Updated: library and wishlist. Store page: people already looking at your store page.

Every single one of those surfaces is aimed at people who already know you exist.

So a devlog on Steam is a retention and reactivation tool. It keeps a wishlist warm, reminds a lapsed player that the game grew, gives a follower a reason to stay, and opens a channel for feedback from the people who care most. That's genuinely valuable — wishlists decay, and a game that looks abandoned converts badly. But it is not an acquisition channel, and treating it as one will make you feel like it's failing when it's actually doing its job.

New people come from somewhere else: search, video, community, press, a Fest. The devlog is what you do with them once they've arrived.

The version most people skip: writing it down

Here's where I'd push back on the standard advice.

The usual devlog recommendation is video-first, because video is what performs on the platforms people think of first. And video does work for reach. But a video devlog with no written version has a specific weakness: it's invisible to anything that reads rather than watches.

Search engines index text. So do the crawlers behind AI answers. A twelve-minute video where you explain how you rebuilt your inventory system is genuinely useful information that, in that form, effectively doesn't exist to them. I've written about this at more length in humans hate text, AI needs it — the short version is that the format that feels worst to make is often the one machines can actually use.

The fix isn't to stop making videos. It's to stop making only videos. The same devlog, written up on your own site, does three things a video can't:

• It's yours. Platform reach is rented. Your site is the channel you own.
• It can rank. A written devlog about a specific problem — pathfinding on hex grids, save systems in Godot — targets real long-tail searches that other developers make.
• It can be quoted. By search results, by AI answers, by someone answering a question on Reddit, by other people learning the same thing you just learned.

Practically: write the post, publish it on your site, and adapt it for Steam and for video. One piece of work, three surfaces, and only one of them can be taken away from you.

A cadence that doesn't eat your project

Some honest calibration, because "post consistently" is easy to say.

Devlogs compete directly with development time, and for a solo developer that trade is real. A weekly video devlog is a part-time content job. That's a legitimate choice — some people build their whole audience that way — but it should be a choice, not something you drift into and then resent.

What I'd suggest instead: tie your devlog to things that actually happened rather than to a calendar. A milestone, a system rebuilt, a genuinely interesting failure. That's the rhythm patch notes already give you for free, and it means you never sit down to write a devlog with nothing to say. Consistency matters less than not burning out — motivation is the resource that actually runs out.

And keep the tiers separate. Small change: patch notes, two minutes. Real progress: a written post. Something you'd actually want a stranger to see: the full treatment, and maybe one of your five rounds.

The short version

A devlog is worth doing. Just be clear about what it's for.

It keeps the people who already found you — followers, wishlisters, owners — from drifting away. It gives Steam something to show them, in seven documented places. It gives you material that, written down, can rank and be cited long after the video stops being recommended.

What it won't do is find you an audience from nothing. Nothing does that on its own.

FAQ