You say that your team should have had the willingness to ship a flawed product sooner, and that maybe that would have changed your fortunes.
If you're ok with sharing, I'd be interested in learning more about why you believe that. Did you hear that from former beta customers later on down the line? Is it an intuition you have from your reflections on the period?
Also, what brand of "perfectionism" are were talking about here? Chasing down minor performance boosts? Gold-plating existing features?
The way I worded it was weird... we never shipped to beta, despite having 4000+ people sign up to be beta testers. We only shipped a "closed beta" (you had to ask one of the devs personally to let you in) to people in our own city. It was a location-based game (like Pokemon go), so there has to be a bunch of people in the area if your actually wanted to do anything fun.
Regarding perfectionism: the game was very rough around the edges in regards to in-game assets. Performance was also a concern, both on the device and the back-end. The device could slow to 1-2 FPS if there were enough assets (100s of troops firing at once - which was easy to do with a few friends playing together at once) animating at once. The server would slow to 4s+ response times if there was enough activity in a single geographic area.
I was okay with shipping with these issues, but the other partners weren't.
"I was okay with shipping with these issues, but the other partners weren't."
Maybe on a different timeline, you would have regretted shipping too early - because first impression matters, too and many people who walk away, after the first try will not come back for second try.
"Really though, we probably would have failed either way, mostly because we didn't know the right people."
Maybe, but from the little I read, it seems like it might have been more the technical challenges (performance) too hard to overcome with the given ressources/target hardware.
Maybe you're right. There were lots of performance issues that were easily solved, like: we were writing to PostgGreSQL for every single game action, our poly counts were in the several hundreds to thousands but could have been well under 100 in many situations, and we were always globally consistent but could have been eventually consistent (through geographic sharding and a "speed of information" data propagation rule -- since all cells don't need any game state from distant cells due to players having to be in a physical geographic location to play). Though I'm sure there were even more huge issues not yet anticipated.
Ultimately, failure was always the mostly likely outcome here, even if we had millions to spend.
The most unfortunate part for me is that we didn't ever get to learn if people actually liked or disliked the game, since we didn't release it outside our own circles.
bookreport is an Austin-based startup providing financial software, data analytics & financial services for K-12 schools. We are optimizing our nation’s $600bn K-12 education spend from the ground up – school by school and dollar by dollar.
bookreport is a growing company; our product is currently used by schools, but there’s still much more to build. You should be comfortable coding in Golang and Typescript (or languages like them), and ideally have some experience with the following: MySQL, React, and Kubernetes.
We're looking for senior or mid-level engineers to come in and help push this awesome product forward.
If you're interested in applying or hearing more about the job and the company, send an email and resume to me at jared@bookreport.io
If you're ok with sharing, I'd be interested in learning more about why you believe that. Did you hear that from former beta customers later on down the line? Is it an intuition you have from your reflections on the period?
Also, what brand of "perfectionism" are were talking about here? Chasing down minor performance boosts? Gold-plating existing features?