Home

Hello Everyone,

My name is Jake Gaylor, and I am a full stack guy. In the last 2.5 years of being a technical founder, I've built and launched two products. While neither of them was very profitable, they both taught me a lot and what to consider the next time. This project is different than my last two because it's consumer facing and free as in beer. (I'm mulling over making it free as in speech as well.) So here we are, one week after the death of my startup, diving back in to the deep end.

I'm not starting this project from scratch nor did I just have the idea. I've had the idea of building this project a couple of times in the past. The first time I started, I created a hubot, and built all the functionality using Hubot scripts. The bot heard its first words while its entire being fit into a single process. The second round at building LoLHubot I knew things had to evolve a bit, and I decided to add an HTTP api server that would do the processing and return the data necessary to construct a meaningful response. I've added modified versions of the api server and 2nd generation LoLHubot to the project as a starting point. The Hubot will remain almost in its entirety while the api server will be rebuilt from the ground up.

I am planning to launch a product, not just build a cool piece of tech. As the technical founder, I didn't spend much time on non-technical areas like a marketing plan (neither did my non-tech founder, that's why we're here!) and that has haunted me recently. For this project I'll be building a landing page using LaunchRock and trying to generate some buzz while collecting email addresses and gamer handles. I will give users access to a closed alpha for inviting others in an attempt to leverage virality and I plan to reach out to twitch streamers as well as those with large communities to spread the word about StatBot. These social advocates can help me reach a targeted audience very quickly as well as add momentum behind the launch.

League of Legends players, especially those not in the top tier of competitive play, often need more information about the game... quickly! It is quite common for players to "alt-tab" to sites like lolking, lolnexus, lolcounter, probuilds, or many others. Once on the site gamers have to type, click, and wait on load times, all while under extreme time pressure. To make matters worse, they often need information from one (or multiple!) source(s) during champion select, another source at the load screen, and yet another during the game. All of these things add to the players' stress level, and some times, they don't get done in time. Thus these constraints have in game ramifications.

StatBot aims to solve this pain point. Through LoLHubot it will provide a chat based interface for retrieving the data gamers need. It is capable of visiting all the necessary data sources simultaneously, aggregating the needed information, and presenting an easily digestible readout to the user to enable him or her to make quick decisions in which they can be confident. Through WebApp and MobileApp StatBot will enable gamers to configure custom commands as well as visualize the results of the commands. While, eventually StatBot will do plenty of things that aren't directly addressing the pain point LoL gamers are facing, solving that problem is absolutely the primary objective.

StatBot is divided into micro services and depends on both a persistent datastore (MongoDB) and an in memory cache (Redis). Each service is run inside of a docker container and deployed from docker images which are rebuilt any time the master branch of the StatBot repository is updated. This approach was easy to setup and it is simple for new people coming in to the project to grok, but it makes it impossible to have multiple versions of a single service deployed in the wild. For this project, I don't need to run multiple versions of a given service since the whole system is deployed as a whole unit. However, this project could quickly outgrow this decision if MobileApp and WebApp were being developed at different paces and compatibility breaking changes needed to be made to the api server to satisfy the development speed of one while the other couldn't be updated in time.

For this application the database choices didn't seem that important. I'm sure there is a ton of relational data that I'm about to store in a non-relational database, but often the data is structureless and the rigor of SQL schemas would have slowed development down. After weighing the pros and cons, MongoDB was chosen to facilitate Meteor being used for the web and mobile applications. Redis was chosen because I'm more familiar with it and its tools.

I hope I've left you with a clear image of where this project started, where it is going, why it exists, and a high level image of how it is structured technically.

Jake