Devlog vs changelog: the story of your game and the record of it

Every indie developer gets the same two pieces of advice: keep a devlog, so people can follow the game before it exists — and keep a changelog, so players can see what changed once it does. The advice is good. The confusion starts because the two look identical from a distance: dated posts about your game, newest first. So teams pick one surface and make it do both jobs, and both jobs suffer. This guide is about what each one is actually for, how to write the devlog half well, and the handoff between them that starts the day a stranger can press Play.

What a devlog actually is

A devlog is a development journal written in public. Its subject is not the game — it is the making of the game: the water shader that took three weekends, the enemy AI that kept walking into walls, the tileset rework, the reason pathfinding is suddenly fast. Its readers chose to follow a project that does not exist yet, which tells you what they want: progress they can see, problems being solved, and evidence that the thing is still alive.

Structurally it is a blog — and it inherits the blog's contract: it owes readers a good read, and it earns the right to skip boring weeks. (The general version of this split is the product blog vs changelog question; a devlog is that story surface wearing a gamedev jacket.) The usual homes: devlog posts attached to your itch.io project page, Steam Community announcements, a thread on a dev forum, YouTube if you work in video. All of these reward the same thing — showing, not describing.

What the changelog is (and when it starts existing)

The changelog — for games, usually patch notes — is the record of what changed in each build people can actually run. Its reader is not a follower enjoying a story; it is a player deciding whether to update, a bug reporter checking whether their crash was fixed, a speedrunner checking whether a trick survived.

Which gives a clean rule for when it starts: the changelog begins at your first public build. Before a demo, a playtest, or an early-access launch, there is nothing to record — nobody runs your builds, so every word you publish is devlog. The day strangers can press Play, the contract flips: every build you ship needs an entry, even a boring one, because the record's promise is coverage. A devlog gets to skip the week nothing interesting happened. Patch notes do not get to skip the build that changed drop rates.

How to write a devlog people actually follow

  • The GIF is the post. Devlogs are a show-don't-tell genre. A ten-second clip of the new grappling hook outperforms four paragraphs describing it; the text's job is to explain what the clip cost you. If a post has nothing to show, that is often a sign it is one week too early.
  • One topic per post. “How I built the water” gets read, shared, and found by other devs searching for water shaders. “October update” — a bit of everything — gets skimmed and forgotten. Roundups are fine occasionally; topics are the engine.
  • Struggle is content. The approach that failed, the profiler screenshot from the bad week, the enemy AI outtakes — half your readers are other developers, and honest difficulty is the most bingeable material the genre has. Polish is what the store page is for.
  • End with state and next. Close every post with one line of where the build stands and one line of what you are attacking next. It turns a scrapbook into a serial — and serials get followed.
  • Pick a cadence you can keep, then keep it. A monthly devlog you sustain for a year beats a weekly one you abandon in six weeks; the cadence you can actually hold is the honest one. And when a gap happens anyway, never open with the apology. “Sorry it's been three months” is the genre's death rattle — it centers your guilt instead of the game. Just post the water shader.

The handoff at early access

Launching a demo or into early access does not end the devlog — it demotes it. From that day the two surfaces split the work:

  • Patch notes carry every build. Dated, complete, symptom-level, exact numbers for balance changes — the full discipline in the patch notes guide. During early access this is also where unstable-build honesty lives: known issues, save-compatibility warnings, what to try this build.
  • The devlog carries the big beats. The biome that took two months, the rewrite retrospective, the roadmap thinking. Selection by interestingness, exactly as before — just no longer pretending to be the record.

Link them asymmetrically. A patch entry for a headline feature gets one line — “Full story on the new weather system: <devlog url>” — and a devlog about shipped work links the canonical patch entry rather than restating the details (they will drift if you restate them). On update day the order is: build live, patch notes published, devlog posted, and socials point at the devlog — one canonical URL per audience, nothing duplicated.

An early-access entry that does both jobs in eight lines:

0.6.0 — 2026-07-30 — The weather update

New: dynamic weather — rain, fog, and wind affect visibility and sound.
Full story on how it works: <devlog url>

Balance: torch burn time 90s → 120s; wolves spawn less at night (6 → 4 per pack).
Fixed: save corruption when quitting during a storm transition (reported by Discord).
Known: waterfalls render black on some AMD cards — fix in progress.
Saves from 0.5.x load fine.

Anti-patterns

  • Devlog-as-patch-notes. The 0.4.2 changes live in paragraph nine of a 1,200-word narrative. Players who want to know whether their crash was fixed will not read your essay to find out, and bug reporters have nothing to cite.
  • Changelog-shaped devlog. The opposite failure: your devlog becomes a bullet list of tweaks. Followers came for the story of the game being made; a record has no plot. They unfollow quietly.
  • The apology spiral. Post, silence, apology-post, longer silence, longer apology. Each apology raises the imagined bar for the next post. Delete the preamble; the comeback post is just a normal post.
  • Future tense in the record. “Coming soon: multiplayer!” inside patch notes. The record is what is true now; promises belong in the devlog or a roadmap you consciously chose to have.
  • A scattered record. Steam got one version of the notes, itch another, Discord a third, each written from memory. Announcements scroll away; keep one canonical changelog with permalinks and let every platform post point at it.
  • The saga with no builds. A twelve-part engine-rewrite series while the game itself ships nothing. Devlogs buy patience, but they cannot buy it forever — a lively record of builds is the strongest evidence the game is real.

Where Wakelog fits

Wakelog is the record half of this pair. Your patch notes get a permanent dated page with per-entry permalinks — the thing you cite in bug-report replies and platform posts — plus tags (new / fix / announcement), RSS, and a Discord webhook so your #patch-notes channel updates itself the moment an entry goes live. Posting fits a build script: one CLI call or one curl when you upload the build.

Two honest caveats. Wakelog will not host your devlog — the story surface belongs on itch.io, Steam, or your own site, where followers already are. And devlogs are a GIF-heavy genre while Wakelog entries are markdown-first text; keep the footage on the story surface and let each patch entry link out to it. One record, one story, each pointing at the other.

Wakelog is a free hosted changelog — post your first patch notes in two minutes, or read the patch notes guide first →

Related guides

Last updated 2026-07-30 · All guides