For The Devs · 2026-05-21

I've Reviewed 50 Steam Demos. Here's What I Learned.

After fifty Steam demos, a pattern emerges. Capsule art makes or breaks discovery, demo length matters less than the moment the game lands, and a quiet Steam page reads as a dead project. Notes from one reviewer for the developers shipping demos right now.

I review Steam demos. Play, Maybe, or Skip. That's the whole system.

I started after looking at a couple of demos that had come to me asking for feedback. I noticed how many were getting pushed out every day, how wide the range of quality was, and how different the dev cycles were behind each one. I started reviewing them. Over 50 now, doing four or five a week.

Out of 51 reviews on the site, three are Skips. That ratio looks generous. It isn't. There's a lot of filtering happening before something makes it into the queue, and most of it happens in the first five seconds. This article is about that. And about everything that happens after.

It's written for developers. Take it as one reviewer's perspective, not gospel.

Steam recent games panel showing a week of demo reviews.
A normal week on my Steam library. Most of these are demos I sat down with for review.

1. Getting found on Steam

Some days there are 30 new demos released on Steam. I'm scrolling through them. I'm making decisions fast. I never even get to playing most of them.

The filter, in order: capsule art, the first five seconds of the preview video, tags, description. That's it. If any of those fail, I'm gone. So is most of your audience.

A few specific things I've noticed:

Capsule art that doesn't match the in-game art is immediately off-putting. If the art style on your store page looks professional and the game looks different, that's a trust problem before the game even loads.

Oversaturated genres get skipped unless something is visually distinctive. Bullet heaven games. Generic 80s pixel art. I've played enough of them that I need a reason to pick up another one. If your game fits into a crowded genre, your capsule art and description have to work harder than everyone else's.

The preview video hook is the capsule art of motion. The first five seconds of your autoplay video is the decision point for people who got past the thumbnail. Start with movement, chaos, or something that needs explaining. Don't start with a logo, a menu, or a slow pan.

Steam new releases page with demo capsules and tag rows.
This is the page I scroll. Capsule, tags, decision. About a second per game.

2. Social media found 20% of my demos

About 80% of what I review I found by scrolling Steam directly. The other 20% came through social posts. Reddit, X, TikTok. Someone posted it, I saw it, it looked interesting, I played it.

20% is not the majority. But it's meaningful. One well-timed post, one creator picking it up, one thread in the right place, and a game that would have stayed buried gets eyes. It costs almost nothing to be active on social heading into demo launch. It can meaningfully move your early traction numbers, and in the first few days on Steam, early traction affects which pages you appear on.

The caveat: build the social presence before you launch the demo, not the day of. If your first post about the demo is the one announcing it's live, you're starting from zero at the worst moment. People who already follow the project are the ones who'll move fast and push early numbers.

3. Announce the demo launch. Then announce every update.

Most Steam demo pages don't use the announcements and events section. This is a mistake.

Announce when the demo goes live on your main Steam page. That sends a notification to everyone who's wishlisted the game. It's a free reach moment most developers skip.

Then do the same for every patch. Every update. Most demos don't get updated at all, or they update silently. A lot of demos never become full games. Players know this. If your page looks quiet, the assumption is the project is dead. A visible update cadence, even small ones, signals that someone is still working on it.

If you get a viral post on social that you weren't planning for, you want the demo to still be up. You want the page to look alive. You never know when that moment happens. Keep it live.

4. Be ready to actually do something with the people who show up

A demo is a public appearance. Once you've made one, you've opened a door. If there's nowhere for people to go after they walk through it, the opportunity is largely wasted.

If someone plays your demo and wants to follow the project, where do they go? Discord? Are you on it? X? Do you post there? Is there a community somewhere that's not just a default empty Steam forum?

If your game is still a year from launch, and you have no socials, no Discord, and no way to collect or respond to feedback, you may have launched the demo too early. Not in terms of the game's quality, but in terms of your readiness to work with the audience it brings in. A demo that builds a wishlist and then goes quiet loses most of that momentum before launch.

Be active in Steam discussions. Link to Discord. Pick one and show up in it. I've had reviews change mid-writing because a developer was clearly reading feedback and pushed a patch in response. That shift in perception matters more than developers probably realise.

Steam page showing a recent events and announcements section with a demo update post.
An active Recent Events and Announcements section is one of the strongest 'this project is alive' signals on Steam.

5. Participate in every festival you can qualify for. But prepare before, not on the day.

This is not new advice. But it's worth saying: Next Fest and similar events produce real traffic spikes, and an early spike in players can push you onto more discovery pages on Steam. The games that go into a festival with early momentum do better than the games that treat the festival as their first marketing moment.

Use socials in the weeks before to build an audience that's ready to move fast when the festival starts. An early spike from people you've already built a relationship with is more valuable than a slow trickle from cold discovery.

6. Don't ask players to do five things at the end of the demo

This is a common one. The demo ends and there's a screen that says: wishlist the game, join our Discord, leave us a review, follow us on X, tell your friends.

That's too many asks. Players do not make five decisions at once. They make one, maybe two.

Pick the CTA that matters most to you right now and commit to it. If you need wishlists, make wishlisting easy and obvious and don't bury it in a list. If you need feedback, make that the single ask. The menu screen is also a good place for a low-friction wishlist nudge, not just the end screen.

Animaly Bar No Humanity main menu with a single prominent WISHLIST NOW button alongside Play.
One CTA, sitting right next to Play. Hard to miss, easy to act on. This is the version that works.

7. How long the demo should be depends on how long it takes to feel the game

I've given a Play to a demo that lasted 15 minutes and ended with 'thanks for playing, please wishlist.' I've also given a Play to a demo I spent over seven hours in before completing.

Both worked because they let me feel the game. That's the benchmark, not the length.

A short demo can work for games with a tight, clear loop that communicates what the experience is fast. A longer demo is usually necessary for games with layered systems, because you need time to get past the learning curve before you can actually appreciate what's there.

The risk with complex games and short demos is that you catch the player before they've clicked. They bounce before the game lands, and they never come back.

Don't worry about spoilers for games that aren't story-driven. If the game is meant to be replayed and mastered, there's nothing to spoil. For story games, an early chapter or prologue works well. The player gets the hook without losing the payoff.

8. Show players what makes the game interesting before they'd unlock it naturally

A demo doesn't have the time for organic progression. If there's a move, ability, or mechanic in your game that you'd normally expect a player to unlock after a couple of hours, put it in the demo early. Let them try it.

You never know which specific mechanic is going to be the one that clicks for a new player. The thing that sells your game to one person might be something another player never discovers in a demo that follows normal progression order. Speedrun them through the good stuff. The demo's job is to sell the game, not to simulate the full game at normal pace.

9. Introduce mechanics one at a time

The flip side of showing everything: don't introduce everything at once.

I'm not going to learn four systems from scratch for a demo. If the tutorial asks me to understand and synthesise multiple new things in the first ten minutes, I'll quit before I get to the part where it gets good. Not because I'm not interested. Because the time investment isn't proportional to what I've committed to yet.

The games that work best ease me in. One mechanic that feels good. Then one more. I'm already enjoying myself before I realise there's more depth coming. That's the right order.

If a reviewer who is actively looking for reasons to recommend the game gives up during the tutorial, someone who downloaded it on a whim will definitely quit before that point.

10. Multiplayer demos are hard. Have a plan or don't do them.

PvP demos are almost always a struggle from a review perspective. Empty lobbies don't tell me anything about whether I'd enjoy the game. Having to join a Discord server to find people to play with before I've decided if I like the game is too much friction.

The options that actually work: bots that demonstrate the real experience, scheduled play windows that are actively promoted beforehand, or enough players seeded at launch that matchmaking actually functions. A multiplayer demo where you open the game and sit in an empty lobby is worse than no demo at all, because it creates a first impression that's hard to undo.

11. Bugs are fine. A broken core loop is not.

Demos don't need to be finished. I know I'm playing something in development. Some of the games I've rated highly had obvious bugs.

What I can't get past is a bug that breaks the core experience. I gave a Skip to one game not because the concept was bad, but because a bug blocked the main mechanic and I couldn't get far enough into it to experience what the game actually was.

The bar is: can I actually play the thing?

12. Read feedback for the problem, not the proposed solution

Players are good at identifying what isn't working. They're usually not good at knowing how to fix it.

When feedback arrives, strip out the emotional language first. Some of it will be phrased badly. Look for what the person is actually describing underneath it. What couldn't they do? What felt wrong? Where did they get stuck?

Take the problem. Don't take the solution they suggested. You're the developer. You know the game. They know their experience.

Respond to all positive reviews. For negative ones, only respond where you have something genuinely useful to say or a meaningful change to flag. You don't have to engage with every piece of feedback publicly.

A negative Steam review describing AI-generated content and shoehorned mechanics in a demo.
Strip the emotional language out and there's a real problem underneath: the core idea isn't being executed on. That's the part to listen to.

13. Track what content creators made about your demo, not just your wishlist numbers

Wishlist numbers are the obvious metric. But they're not the only signal.

Look at what content was created around the demo. Shorts, videos, written reviews. How many pieces? How did they perform compared to that creator's normal content? If a creator who normally averages 500 views put your game out and got 2,000, something about your game overperformed for their audience. That's a signal worth noting, even if the absolute number is small.

Engage with that content. A retweet costs nothing. A comment costs nothing. For an independent creator building a channel from scratch, developer acknowledgement does more for the relationship than most developers realise. You're not managing a press cycle. You're building a connection with someone who is actively telling people about your game. The ones who notice get reviewed again at full launch.

Who I am, and why that context matters

Feedback is only useful if you know who it's coming from.

I'm in the 35-40 bracket. Three kids. I've been gaming since I was about 12. I don't have the time I used to, so I'm selective. On evenings where I don't want to think, I go to what I call brain-rot games. Battlefield 6, League of Legends, WoW Hardcore. Games I already know how to play and can play on autopilot whilst watching my shows.

My audience looks almost identical to me. Across platforms, it runs almost entirely male, almost entirely in the 30-40 range from UK, EU, and US. So the feedback you're reading here, and the feedback that comes from reviews and comments on todaywegame.gg content, is filtered through that lens. If your game is built for a different demographic, some of this will apply less.

Take it as one data point. A useful one, hopefully, from someone who has played a lot of these and will play a lot more.

All Steam demo reviews at todaywegame.gg. Play, Maybe, or Skip.


More For The Devs articles