How to Get Your First 100 Steam Wishlists

Your first hundred Steam wishlists come from four sources: the people who already know you, the communities you genuinely take part in, a devlog kept on a schedule, and a playable demo that strangers find on their own, all of it landing on a store page that converts. None of it costs money. All of it costs consistency, and the part most developers get wrong is aiming one big announcement at everyone instead of working a short list of channels slowly.

The request arrives weekly in the community reads we run: the page is live, the counter sits at double digits, and the post reads like the one we saw on r/gamedev, "98 Wishlists on Steam! Help me get it past a hundred!" A hundred is a small number that behaves like a large one, because the distance from zero to a hundred is where every channel gets invented for the first time. This article is the operational answer: what to fix on the page first, where each batch of wishlists actually comes from, what a realistic sequence looks like, and which shortcuts quietly poison the number. A disclosure before we start: this blog belongs to Egmatic, a no-code 2D editor in pre-alpha, and what that has to do with wishlists is near the end.

Quick answer#

If you want the surrounding system instead of the tactic, the zero-budget marketing walkthrough covers how wishlists fit the whole pre-launch machine; this piece stays on the narrow question of getting from zero to a hundred. How many wishlists convert into sales once you launch is a separate question with uncomfortable answers, and it deserves its own treatment.

What the first hundred are actually for#

A wishlist is a bookmark with a trigger attached. When you press release, Steam automatically emails everyone who wishlisted the game. That email is the most reliable conversion event a small game gets, which is why the pre-launch period is largely an exercise in growing the list it lands on. Wishlists also feed the visibility decisions Steam makes about your release, so the list you build decides both the size of your first wave and how hard the store works for you afterward.

Two properties of wishlists surprise people, both documented by Valve. First, they barely decay: Valve's Coming Soon guidance notes that a player who wishlists two years before release is about as likely to buy as one who wishlists two weeks out, so an early page is not premature. Second, the hundred mark itself unlocks nothing. There is no badge, no algorithm tier, no Valve email of congratulations. Its value is diagnostic: a game that cannot reach a hundred strangers has usually not yet built the page, the community habit, or the playable slice that the next thousand would come from, and finding that out at 98 is cheap.

The number to watch during the climb is weekly additions, not the total. Twenty wishlists a week for five weeks means four working channels. A hundred wishlists in one spike and silence after means one lucky placement and nothing to build on. Our launch day checklist treats the wishlist count as one of the baseline numbers you record on release day; getting to a hundred honestly is how you make that baseline mean something.

Fix the page before you chase anyone#

Every minute spent promoting a page that does not convert is a minute spent refilling a leaking bucket. Valve's Coming Soon checklist asks for a set of branding images, a written description, and ideally a gameplay trailer; in practice that means a capsule that reads at thumbnail size, screenshots of actual gameplay rather than key art, and a trailer cut from that same gameplay. Accurate tags matter too, because tags and genre choices decide where the page surfaces in category listings. Valve's own documentation is the authority here, and our Steam Direct walkthrough walks through the whole setup from the $100 fee onward.

The timing rules come from Valve's Coming Soon documentation and are stricter than most developers assume. A new product's Coming Soon page must be public for at least two weeks before release, and that is a floor, not a target. Store page review itself needs a buffer: Valve asks you to submit the page at least seven business days before you want it live. A page that goes up in the release month collects almost nothing, and launching into silence costs you the one visibility window a first game gets. The two-week minimum exists precisely so there is something to email on day one.

One honest caveat from the same documentation: publish when you are confident about the art direction and the core of the game, not before. Wishlisting is a bet on what the player saw, and a page that promises a game you later abandon embarrasses you twice, once to the players and once to the list you spent months building.

Where the first hundred come from#

The first hundred are not one audience. They are four, each with its own mechanics and its own failure mode.

The people who already know you#

Friends, family, former colleagues, the group chat that has watched you build this for a year. This tier supplies the first 10 to 30 wishlists in most honest post-mortems, and its value is mechanical rather than sentimental: a small visible count makes the page look alive to the next stranger. The ask should be direct and individual, one message per person, with the link and one sentence about what the game is. A broadcast to two hundred contacts converts almost nobody; fifteen personal messages convert most of the fifteen. Ask them to tell one friend if they like the look of it, and stop there.

Communities you take part in, not post at#

Subreddits, Discords, and forums where your future players already gather. This tier works on a deposit-withdrawal rhythm: answer questions, share what you are learning, be a resident for a few weeks, and the post where you finally share your page arrives as a neighbor's project rather than an ad. The failure mode is the drive-by link, which most communities delete and all communities remember. Our piece on building a game community before launch covers the mechanics of choosing and feeding these places; the short version is two communities you actually visit, not nine you spam.

Developer communities deserve a separate note because they convert differently. r/playtesters and its siblings supply testers rather than customers, but a tester who enjoyed the build is far more likely to wishlist than a stranger who has only seen screenshots, because they have already played. If you are running playtest rounds, and you should be, every round ends with the same sentence: the page is here, wishlist it if you want to know when it ships.

A devlog that points at one link#

A build-in-public loop on itch.io, a substack, or a video channel, updated on a schedule you can keep for months. The devlog rarely produces wishlists directly; it produces them the second and third time a reader encounters your game, when familiarity finishes the job a single impression could not. In the community reads we run, the zero-budget post-mortems that reached meaningful wishlist numbers were long grinds, one of them eleven months to roughly two thousand wishlists, and the ones that stalled were usually posts without a schedule behind them. Every devlog entry should end with the store link, and nothing else to click.

A demo, and the festival built around it#

The demo is the only tier where strangers find you instead of the reverse. A publicly playable slice is its own App ID attached to the base game, and Steam wires the path back for you: the demo's page carries a prominent automatic link to the full game, demo players see another link in their library, and demos can surface anywhere a free game can, including the New and Trending lists and the tag and genre pages where browsing strangers find them.

It converts visitors in a way no screenshot can, and it qualifies the game for Steam Next Fest, the weeklong event Valve runs three times a year in February, June, and October. Next Fest puts unreleased games with demos in front of a large audience that came specifically to browse them, and for an unknown developer it is the largest concentrated source of wishlists that exists on the platform.

The rules have teeth, and they are all documented by Valve. A title may participate in exactly one Next Fest, ever, so spend it near launch rather than the moment a build exists. Registration happens on the base game's app landing page, and the demo must be submitted for build review no later than three weeks before the fest starts, five weeks if you want it live for the press preview. During the event, placement is randomized for the first days and then personalized by player behavior, which means the fest rewards a polished demo rather than a clever launch minute. When your demo goes live at any point, wishlisters can be emailed about it exactly once, and you have a 14-day window from demo launch to press that button; it does not come back.

For timing, the calendar matters. The October 2026 edition runs October 19 to 26, and its registration closed in late August, so a game not already registered is aiming at the February 2027 edition. Valve publishes each edition's dates and registration window on the Steamworks events pages as the fest approaches. That lead time is not a problem; it is the schedule your first hundred should be built around.

What each tier contributes#

Those ranges are observations from community post-mortems rather than measurements, and your mix will differ. The shape is the point: no single channel produces a hundred, and the channels that look fastest, the personal ones, run out first.

A sequence that works#

The order matters more than the speed.

1. Submit the store page for review this week. Seven business days of review, then the page collects wishlists while you do everything else.
2. Spend the first week on personal asks. Fifteen individual messages beat one announcement post. Bank the first 20 and move on.
3. Pick two communities and become a resident. A month of participation before your first share. While that clock runs, start the devlog on a weekly or biweekly schedule you can hold.
4. Cut the demo slice in parallel. Small, polished, ending on a hook. Run it past one playtest round before it goes public.
5. Register for the Next Fest nearest your realistic launch. Count back three weeks from the fest start to submit the demo for build review, five if you want the press preview, and add buffer for a failed first review.
6. Press the demo email button inside its 14-day window. One email to everyone who already wishlisted, and Steam enforces a two-week cooldown per App ID on such notifications, so space it away from any other wishlist trigger like a discount. It does not repeat.

Common mistakes#

Buying wishlists, or rewarding them. Steam sells no advertising anywhere on the platform, so paid wishlist services are by definition off-platform manipulation. The farmed accounts never buy, the release email lands in dead inboxes, and the launch then reads as a failure to every system watching it. Reward schemes, a skin for wishlisting and the like, poison the same signal: the count stops meaning demand. This is the one mistake that costs you the number itself, not just the money.

Treating the two-week minimum as a plan. The Coming Soon page must be public two weeks before release at absolute minimum. A page that goes up a month before release has a month to collect, and that is not a runway, it is a formality. A first game should aim its page at a season, not a date.

Counting followers instead. Discord members and social followers do not become an email on release day; wishlists do. Track the number that converts.

Skipping the demo. Every channel above multiplies a playable slice. Without one, the personal and community tiers run dry well short of a hundred and the curve goes flat.

Spending Next Fest early. One fest per title, ever. The edition that matters is the one closest to a launch-ready build, not the one with the nearest deadline.

How Egmatic fits#

The bottleneck in the sequence above is rarely ideas; it is builds. The demo slice, the playtest round that precedes it, the web version, the weekly update that keeps the devlog honest, each of those is a shipping task, and in most editors each is also a separate detour of export settings, wrappers, and upload pipelines. That assembly line is the ship layer, the publishing half of game development, and it is the half Egmatic is built around: a no-code 2D editor and engine where the tool that assembles the scenes is the same tool that carries them to players. The AI inside works as a craft amplifier under your direction: you decide what changes, it executes, and every file stays yours, which matters when the demo needs its fourth rebuild the week before build review.

We will state the stage plainly: Egmatic is pre-alpha, and we do not announce dates we cannot keep. The waitlist at egmatic.com is where the ship layer takes shape, and it is where you can tell us what your pre-launch loop is missing, because in pre-alpha the requests arriving now are the ones that steer the build.

Ship the demo. Earn the wishlist.

The first hundred wishlists come from a page plus a playable build in front of strangers, and that loop is the publishing half of game development. Egmatic is a no-code 2D editor with a ship layer that carries scenes to players without code or a backend. Reply on the waitlist with what your pre-launch loop is missing: requests sent during pre-alpha are the ones that steer the build.

you@example.comGet Build News

No spam. Unsubscribe anytime.

Conclusion#

A hundred wishlists is four small campaigns, not one big one: a page that converts, direct individual asks to the people who know you, residency in two communities, and a demo timed to the Next Fest nearest your launch. Every tier is free, every tier compounds, and the total arrives in the order listed, personal first, festival last. The number itself unlocks nothing, but the machinery you build reaching it is the same machinery that carries the next thousand, the launch email, and the game after this one. Once the page is live, the work is a schedule; put the store link at the end of everything you post, and keep posting.

Sources#

1. Valve — Coming Soon (Steamworks Documentation) (two-week minimum Coming Soon page before release; seven business days for store page review; automatic release email to wishlisters; long-lead wishlists purchase at similar rates)
2. Valve — Steam Next Fest (Steamworks Documentation) (weeklong, three times a year; one Next Fest per title ever; public demo required; three-week and five-week deadlines to submit the demo for build review; randomized then personalized placement; one-time demo notification email within 14 days of demo launch; no paid advertising on Steam; Playtest live during a fest splits players)
3. Valve — Steam Direct (Steamworks Documentation) (the $100 fee per product, recoupable after $1,000 in adjusted gross revenue)
4. Valve — Demos (Steamworks Documentation) (a demo is a separate App ID attached to the base game; automatic links from the demo page and the player's library back to the full game; demos surface in New and Trending and tag and genre pages; one-time wishlist notification within 14 days of demo launch, two-week cooldown per App ID)
5. Steam — Next Fest (the event from the player side)
6. Community reads run by our team, September 2026: r/gamedev post "98 Wishlists on Steam! Help me get it past a hundred!" and $0-budget wishlist post-mortems including roughly two thousand wishlists across eleven months of devlogs; r/playtesters as a recurring source of testers who wishlist after playing