Publishing Strategy
What a publisher actually reads in your pitch deck
A publisher evaluates your game by building a risk model. Most developers present their pitch as a story about the game. The publisher reads it as a story about what can go wrong.
At Raw Fury I picked projects up after the deal was signed, which is where you find out what the deck actually promised. The games nearly always looked interesting. What decided how the next two years went was whether there was a viable path from that deck to a shipped game, and how much risk sat between here and there.
There are five categories of risk that come up in some form on almost every project. Knowing what they are doesn't change whether your game is a good pitch. But it changes how you prepare, and it changes which gaps in your deck are going to generate the most questions.
Creative risk
Every game has a few things it absolutely has to get right to reach its potential. The publisher is trying to work out what those are, and whether the team has identified them.
For one game it's the core loop: if the base gameplay isn't satisfying in the first ten minutes, nothing else matters. For another it's the writing, or the visual identity, or the pacing of the mid-game. A publisher reading a deck is looking for evidence that the team knows which parts need to be exceptional, treating that as separate from the launch feature list.
A prototype or vertical slice that demonstrates exactly the part of the game that needs to work is very useful at this stage. It works as proof that the team knows what the concept is and has already tested whether it lands. Nobody expects the whole thing to be built yet.
Financial viability
Every publishing deal is a bet on whether the total cost to bring the game to market makes sense relative to the revenue opportunity. The publisher is doing that math before they get excited about the concept.
The proposed development budget, the publisher's own service costs (porting, QA, localisation, marketing), and a realistic projection of what the game can earn need to be in the right order of magnitude relative to each other. 500,000 euros of realistic lifetime revenue will not carry a development budget of 400,000 euros plus full publishing services. The math doesn't close, and I have watched that arithmetic get done out loud, in about thirty seconds, in a meeting the developer was not in.
Where developers get caught is the direction of that comparison. The instinct is to start from what the game costs to build and work outward. A publisher starts from the ceiling and works back, and a ceiling of 500,000 euros has to absorb the platform cut, the service costs and the advance before anyone gets to argue about the split. Run your own numbers in that order before the meeting, because the person across the table already has.
This is also where market awareness matters. Bring comparable titles, their sales performance, and a clear read on what the game positions against, and you get a different conversation from the deck that rests on the game being good. Publishers have seen a lot of pitches that rely on the game being good.
The same math keeps running after the deal is signed, in the recoupment waterfall that sits behind these numbers.
Commercial opportunity
Is there an audience for this game, and is that audience reachable at a cost that makes the deal work?
Some genres are crowded in a way that makes break-through genuinely difficult and expensive. Others have clear player appetite and not many good options. A game in a saturated space needs a specific answer to why someone would buy this instead of the ten similar titles already available on sale. A game in a cleaner space has more room, though "cleaner space" can also mean "smaller audience," which is its own problem.
The timing and positioning questions matter here. Who is this game for? Where do those players go to find new games? Is there a community that already exists, or does one need to be built from nothing? You pay far less to launch into a conversation that already exists than to start one from nothing. The pitches I had the least confidence in were the ones that answered "who is this for" with a genre name.
Technical risk
New technology, networked multiplayer, custom engine work, large open worlds, procedural generation at scale. All of these carry execution risk that's hard to assess from the outside and easy to underestimate from the inside.
What happens when a team pushes an engine well beyond its comfortable range, or implements a technology nobody there has used before? Unknowns, in volume. That's fine if it's accounted for in the schedule and the team has the experience to navigate it. It's a problem if the plan assumes everything goes smoothly, because it won't.
What publishers respond well to is honesty about the hard parts. Name the technical challenges and explain how you are approaching them. It reads as more credible than silence, every time. Everyone who has shipped knows the hard parts always show up. I have never once seen a schedule survive first contact with a certification queue. Teams that already know that are easier to work with than the ones still finding out.
Team and execution
Underneath all of it is whether the team can make the game.
Has this team shipped something of similar scope before, in this engine, together? Together, and on something that actually shipped. Both halves of that matter, and teams tend to answer only the half they can. Having shipped once, even something small, a team has already solved most of the hard coordination problems. Execution risk of that kind never shows up as a line in the budget, which is why a first project at this scale makes publishers uneasy.
Processes matter here too, in a boring operational sense. The publisher is trying to work out whether milestone updates will be reliable, whether scope decisions get made or argued about for months, and whether the people in the room will still be working together eighteen months from now. A clear lead with actual decision-making authority and a team that has functioned under pressure before is a different risk profile from a collaborative structure where no one is obviously accountable.
On one project I picked up after signature, the entire rendering pipeline lived in a single programmer's head and none of it was written down. They left mid-development, and the team spent most of a milestone rebuilding knowledge that had walked out with them.
Team conflicts, unresolved co-founder dynamics, key dependencies on one person who is also the lead programmer and the art director. These come out eventually. I would rather hear about them on a call than discover them in month nine, and so would the publisher.
Pitch deck shaping and review is part of my Strategic Publishing Support service. More guides and tools live in the resources hub.