Release Early, Release Often for Mobile Games

12 Feb 2011

As I'm closing in on the launch of my first game, I've come across a million things that I wish I had more time to work on. My grand vision when I started this thing has turned into a race to the finish where I drop everything non-essential so I can get it out the door. Recently I'd been feeling discouraged, so I took a few moments to stop and get some perspective.

In everything I've learned about building web applications, "Release Early, Release Often" is the mantra. It's definitely better to get things out in front of your customers early so you can see how they want to use it and pivot. It's also easier to manage a release cycle that's a few days (or hours) long, rather than a six month project. For apps, especially those in hit-driven fields like games, this seems to make a little less sense. It's not like you can put out a half-baked first level and hope your customers will keep it around long enough to update when you get around to putting out level two or fixing your terrible control scheme. These types of apps typically only have one shot of attracting a user. The part I forgot about is that in a hit-driven field, you're banking on the fact that you're going to be releasing frequently. You're also relying on reusing technology, process, or marketing improvements that were factored into your current project.

If you go look through a timeline of releases from some of the top iOS game companies out there, their first games weren't 3D immersive techfests. Some of them weren't even all that fun! The key is that their next titles were usually more complex and better made. It's OK to put out a product that doesn't live up to your expectations, so long as you incorporate as much as possible into your next project.