The Perils of Critical Success

One of the repercussions of crowdfunding is that more and more people are learning advanced financial concepts the hard way. One of the most counter-intuitive of those concepts is that of problematic success: where your plans succeed beyond the capacity you’ve planned or budgeted for fulfillment.

Flight Rising is a good example of this.

In spring of this year, Stormlight Workshop ran a Kickstarter to pay for the costs of launching their dragon-pet game (have a look at their project here). They asked for $3500, a goal they hit within 24 hours. Their month-long campaign started unlocking stretch goals in the first week; they launched on the 9th of March and by the 11th they’d unlocked two stretch goals. By the 18th, they’d hit $20,000 and a fourth stretch goal. By the end of the funding period, they’d unlocked six stretch goals and reached a total of $38,557. That’s 1000%+ over their goal.

Several months later, the game debuted at the beginning of June. Within a month, it started experiencing significant problems with load. It’s now the beginning of August and the issues have become so severe there are daily periods where the entire website is unavailable (and stays unavailable, sometimes for over an hour)…and when the site is up, half its functionality is either so impaired it’s unusable or it’s completely unavailable.

The coders report they are hard at work attempting to optimize the code, and at some point they were supposed to get additional servers, but so far they haven’t managed to solve their popularity problems; they have in fact shut down new user sign-ups for now.

Now, I love Flight Rising: it’s a clever game, the art is gorgeous and colorful, and it has a lot of potential. I’m hoping they solve their issues. But at the same time, they should have seen this coming. The most popular pledge level for their Kickstarter was the $40 “All The Things” prize. Assuming that most of their backers pledged at that level, they designed the project to be funded by about a hundred people, and probably planned their server needs accordingly. The moment their project hit its funding goal in the first day, someone should have sat down and said, “Okay. We’ve underestimated our starting user base. We need to plan for more people than we thought. Let’s watch our backer numbers and start speccing out different solutions; we’ll eventually want to go with the one that can support double the number of backers we end up with at project close.”

I suspect what happened instead was that they got very excited that their game was going to be more popular than they thought and rushed it to market to serve the demand before it could evaporate…without understanding that launching an underpowered solution would cost them more in players than it would have to wait until they’d set it up properly.

The ability to forecast the amount of effort you’ll need to put forth in response to success—basically, the ability to predict whether you can scale your operation—is something most people have no experience with, but it’s vital. You can afford to handmake prizes for ten people. What if one thousand show up? Ten thousand? Crowdfunding forces normal people to confront the same issues that inspired assembly lines and the move to mass production. It’s not enough to think like a person who needs money. If you’re doing something like this, you have to think like an entrepreneur.

This is not the first story of a successful crowdfunding initiative outrunning its creators’ ability to plan for that success; here’s one about a man who lost his house when his successful Kickstarter started incurring debts faster than he could pay them. Until people get used to having the power to succeed, they’re going to make mistakes, sometimes very costly ones.

Remember folks: it’s not enough to plan for critical failures. Critical success comes with its own price. Keep both possibilities in mind before you launch.

Leave a Comment


NOTE - You can use these HTML tags and attributes:
<a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>