Quick answer: Send review keys 2-3 weeks before launch so coverage can land at release, and use an embargo (a stated 'reviews may publish from' time) when you're coordinating a launch moment — it pools coverage into one wave and reassures outlets nobody scooped them. For indies the process is a spreadsheet: who got keys, against what date, with one clear embargo line in every email.
Send review keys 2-3 weeks before launch so coverage can land at release, and use an embargo (a stated 'reviews may publish from' time) when you're coordinating a launch moment — it pools coverage into one wave and reassures outlets nobody scooped them. For indies the process is a spreadsheet: who got keys, against what date, with one clear embargo line in every email. That's the short version — the sections below get into the how, the why, and the mistakes worth dodging.
Why embargoes serve small games too
An embargo isn't AAA secrecy theater; it's coverage synchronization: reviews landing scattered across three weeks each evaporate alone, while the same five reviews publishing within launch's 48 hours create the simultaneous-chatter effect that algorithms and humans both read as 'this game is happening'. It also de-risks early keys — outlets can play for two weeks without racing each other to publish first.
Keep it simple and stated identically everywhere: 'Review embargo lifts [date, time, timezone]'. One line in the key email, repeated in the presskit. Indies don't need NDAs for this — the embargo email convention is well-understood and overwhelmingly respected.
The distribution mechanics
Timeline: keys out 2-3 weeks pre-launch (longer for big or long games), targeted to your researched press/creator list plus vetted inbound requests (verify identities — key scammers love embargo season). Track in a sheet: outlet, contact, key, date sent, embargo acknowledged, coverage landed. Steam keys via Steamworks in a tagged batch so the review-copy batch is auditable and revocable.
The build they get should be your release candidate with crash reporting enabled — press machines are a hardware sample, and a reviewer's crash is both a coverage risk and a free pre-launch bug report. Include the presskit link and a 'known issues being fixed for day one' note where honest; reviewers respect candor and punish surprises.
Edge cases at indie scale
Streamers blur the embargo picture: video creators often want day-one or pre-launch content windows rather than review timing — set creator-specific terms ('videos may go live [date]') and remember an embargo on opinions is normal while paid-coverage rules are a separate, disclosed thing. Scores-versus-impressions embargo splits are AAA practice you don't need.
When coverage breaks embargo (it happens, usually by sloppiness): one polite note, escalate never, and remember the relationship math — a small outlet's early review costs you little, while public embargo drama costs goodwill across the whole press list. And if nobody covers you at all, the keys still served: every contact is a warmer lead for the next beat, and the next game.
Marketing is a generosity game
The indie marketing that works rarely looks like advertising. It looks like sharing something genuinely interesting: a clip that makes people grin, a devlog that teaches something, a thread about a problem you solved. People share what makes them look good for sharing it.
So lead with the most interesting true thing about your game, not with the ask. 'Wishlist now' earns nothing by itself; a great 15-second clip earns the wishlist without asking twice.
Consistency compounds, virality doesn't
Every indie knows one game that blew up from a single tweet, and that story wrecks more marketing plans than it helps. Viral moments are lottery tickets. The reliable curve is slower: post regularly, get a little better each time, and let followers accumulate like interest.
Pick a cadence you can sustain on your worst week — one post, one clip, one devlog — and hold it for months. The audience you build that way actually shows up on launch day.
Plan for the bugs you won't see coming
Whatever else you take from this, build yourself a way to hear about problems. Once your game is on other people's machines, most failures happen out of sight: the crash on hardware you don't own, the save that corrupts once in fifty exits, the bug players mention in a review instead of a report.
A lightweight crash and bug reporting setup — even just Bugnet's free tier wired into your engine — turns that silence into a fixable list. The devs who look calm at launch aren't luckier; they just see their problems earlier.
Putting it to work
Don't try to act on all of this at once. Pick the one change that costs you the least and pays the most this week, do it, and see what actually happens before reaching for the next.
Most of this rewards steadiness over intensity. A small improvement made every week, checked against how real players respond, outruns any single burst of effort — in this corner of game development and every other one.
Show up where your players already are, lead with the interesting thing, and keep the cadence.