The build is signed off. The maths has been checked, the art is final, and the bonus round lands the way it did in the design doc. Somebody in the studio opens a bottle. Then someone asks when players will actually see it, and the room gets quieter.
For a lot of studios the honest answer is: not for a while. Nothing is wrong with the game. The trouble is that finishing a game and getting it into a market are two separate projects, and only the first one was on the plan.
The day after “done”
The morning after sign-off, the to-do list looks nothing like the one from the week before. Almost nothing on it is about gameplay. Most of it is about proving things to people who haven't seen the game yet, and agreeing terms with people who haven't decided whether they want it.
- Certification. An accredited test lab needs the build, the maths documentation and the RNG evidence, and it will test against the requirements of each market you want to enter.
- Jurisdiction requirements. Markets have their own views on RTP ranges, autoplay, spin speed, feature buys and responsible-gaming messaging. Some of those views mean build changes.
- A route to operators. The game has to be hosted somewhere operators can reach, through a game server they're already connected to or one they're willing to integrate.
- Commercial terms. Somebody has to agree revenue share, reporting, invoicing and who is responsible when something goes wrong.
- Operator onboarding. Each operator runs its own QA, wants its own assets and sets its own go-live date.
None of these are exotic. Every studio that has shipped a game has been through them. The problem is that they arrive all at once, right after the team that built the game has spent everything it had on building it.
Why good games sit on the shelf
It's tempting to assume a game waits because it isn't good enough. In practice, games wait for much duller reasons.
They wait for a test lab slot. They wait for a change request because one market needs a different RTP variant and the maths team has already moved on to the next title. They wait for a contract to come back from legal. They wait because the one operator who said yes has a content freeze around a major sporting event.
Each of these delays is reasonable on its own. Together they stack. A studio can lose months between “done” and “live” without anyone doing anything wrong. And a game designed for a moment, a seasonal theme or a trend players care about right now, can lose that moment while it sits in the queue.
The work lands on nobody's desk
Part of why this is hard is organisational. In a small studio, the people who are good at making games are rarely the people who want to chase lab reports or negotiate reporting formats. In a bigger studio there might be a compliance lead and a commercial team, but they're usually shared across many titles and many requests.
So the post-build work falls into a gap. It isn't creative, so the creative team doesn't own it. It's specific to this one game, so the central teams treat it as a ticket. Everyone is busy, and the game waits.
Smaller studios feel this most. A large supplier has been round the certification loop enough times to have templates, relationships and a known timeline. A new studio is often doing it for the first time, while also trying to build its second game.
Questions worth asking before the next build
If the distance between done and live keeps catching your studio out, it helps to ask a few questions at the start of the next project instead of at the end.
Which markets is this game actually for, and what do their rules mean for the maths and features we're about to lock? Who owns certification, and when does the lab need to see documentation? Which operators do we expect to launch with, and do we already have a way to reach them? What will they need from us beyond the game itself?
None of those questions are hard to answer early. Almost all of them are expensive to answer late. The studios that launch quickly tend to treat the market as a design constraint from the first sprint, not as a problem to solve after the last one.
What changes when the path already exists
Imagine the same morning after sign-off, but the route to market was in place before the game was.
The game was built on infrastructure that already handles the game server and the RNG. The documentation certification needs was produced during the build rather than reconstructed afterwards. Market rules are configuration, so an RTP variant is a setting rather than a new branch of the code. The connection to operators already exists, so shipping to one more of them doesn't open a new integration project.
The studio still has decisions to make: which markets first, which operators, how to launch. But those are the decisions a studio should be making. The paperwork stops being the thing that sets the timeline.
Where Raise Engine fits
This is the problem we built Raise Engine around. Creators build their games on it, and the infrastructure that normally arrives as a second project, from certification and jurisdiction paperwork to the path to operators, is already underneath them. You ship the game. The platform ships everything around it.
The build being done should feel like the finish line. For too many studios, it's still the starting gun for a race they didn't enter.
.gif)
