Check out photos of this project
Check out architectural diagrams of this project
What was the problem to be solved?
Jared Ginsberg, CEO of Class Act Sports, LLC, needed to build a new fantasy sports app to complement his company's suite of already popular apps.
The company had already launched two fantasy sports apps: Brack Attack and Gone Streaking.
The NFL game, Class Act Survivor would complete that suite with an innovative game that allowed users to play weekly games in an eliminator style.
Eliminators had become popular in fantasy sports, but traditional eliminators went like this: Each week participants pick a team to win a game. That team is ineligible to be picked by that participant the REST of the year.
If your team wins, you move on. If your team loses, you're eliminated.
The last participant standing wins the pool.
Class Act Survivor was similar, but with a twist.
Instead of choosing a team to win, you picked players to reach certain statistical milestones.
For example, each week, you have to pick a running back to get to 100 yards, a quarterback to throw for 200 yards and a receiver to go for 150 yards.
Once you pick a player, you can't pick that player again.
Entry fees ranged depending on the league and new leagues started each week.
What was the proposed solution?
We proposed to deliver a product that was natively available on Android and iOS devices as well as on any internet-connected device.
The design needed to be simple as we were trying to pack a lot of information into small screens.
Finally, the game had to be conducive to sport fans and non-sports fans alike.
What challenges arose during the project?
1) Budget - The initial budget of $60,000 would have been plenty except for the challenges that arose from #2 and #3. However, given those two issues, the budget quickly became an issue we had to work around.
2) Timeline - The project was initially slated to start on January first with a six month development timeline, followed by three months of internal testing leading up to the launch of the NFL season in September. However, the project was delayed for five months from Class Act Sports, LLC and we didn't actually start until nearly June (which was our initial target date).
Unfortunately, the start of the NFL season can't be moved, which meant we had to squeeze six months of development into 3.5 months with no room for QA.
3) Scope Creep - Scope creep became a real challenge for this project. Requirements weren't communicated clearly and what originally started as a game that participants had to enter prior to the NFL season, became a group with new leagues starting each week of the NFL season.
Additionally, design was a constant challenge throughout this project and drew a lot of focus away from optimizing the functionality of the game.
4) Legal Issues - At the time, sports betting was still up in the air, and the legality of the app changed from seemingly week to week. We had to constantly change the app to account for these requirements, including verifying users and changing the way and method we took payment - for example, initially it was direct cash to enter leagues and get paid, then it changed to purchasing tokens which could then be used to enter leagues and winnings were paid out in tokens which could be exchanged for cash.
5) Testing - Aside from the fact that we didn't have time for testing, we had the issue of replicating live data to use to test the functionality of the app.
What was the technical approach to the project?
As with most apps, Class Act Survivor needed to be available on desktop and mobile devices.
And as with most projects, budget and timeline were tight.
We used the same API for both versions which saved us a great deal of development time.
GraphQL (instead of REST) made this possible in a performant way.
We were able to only request the data we needed and cache it for offline use on the mobile version (which needed less data per screen).
The flexibility of the Apollo framework made it so all we had to do was change the visual components of the app between the desktop and mobile versions.
We used an API from Opta Sports for real-time and historical data that we parsed using Lambda, SNS and SQS and stored in DynamoDB tables.
What was the project management approach to the project?
Using Agile Scrum, we took an iterative approach to this project with a team consisting of a back-end engineer, frontend engineer, a designer and a project manager - with each iteration lasting one week.
We started out with nothing (no mocks, no wireframes, etc), so we started with a two Research Sprints.
This was followed by two design sprints in which we mocked out the UI.
However, instead of using design tools like Photoshop, we did it using React with mock data.
This allowed the stakeholders to see exactly what the UI would look like when the app was fully functional.
After we had an agreed-upon UI (which unfortunately didn't hold), we began our usual pattern:
1) One week function sprint where we added new functionality
2) One week QA sprint
3) One week bug fix sprint
Repeat until finished.
This was absolutely necessary due to the shifting requirements and scope mentioned in the challenges section.
What platform was built for this project?
As this was a new product, we knew that initial usage would be very low and we were working with a near non-existent hosting budget, so a traditional, redundant, fault-tolerant architecture was unrealistic and wasteful.
However, using Serverless with AWS allowed for us to create a setup that will scale infinitely and immediately with no additional changes need from us. The cost will increase with usage, but at that point, the app will be generating revenue.
In the meantime, the setup runs itself for less than $15 a month.
We relied heavily on AWS AppSync to accomplish this.
AWS AppSync automatically updates the data in web and mobile applications in real time, and updates data for offline users as soon as they reconnect. AWS AppSync makes it easy to build collaborative mobile and web applications that deliver responsive, collaborative user experiences.
AppSync let us specify the data requirements of the application with simple code statements and iterate quickly during the prototyping and development process.
AppSync uses GraphQL, an open standard query language that makes it easy for applications to request data from the cloud.
AppSync automatically manages all the data operations for offline users. The service supports an offline programming model where application data is not only available for users who are offline, but users can also add and update app data locally as well. This makes it easy to build apps that cache important data locally for offline use, and then synchronize with the cloud when the device reconnects.
The service integrates with Amazon Cognito and AWS Identity and Access Management, allowing us to set fine-grained permissions on GraphQL operations that put strict controls on who can access the data.
AppSync makes it easy to combine data from different sources. With AppSync, we could access data in Amazon DynamoDB, trigger AWS Lambda functions, or run Amazon Elasticsearch queries and combine data from these services to provide the exact data we needed.
What did you learn from working on this project?
We learned a lot about structuring Microservices for development.
This can be a challenge when you have several Serverless functions that are all disparate.
How do you make sure the code is all accessible and understandable?
We took the approach of putting them all in a single github repository but managed separately using the Serverless framework.
How did this project benefit the client?
As mentioned, when Class Act Sports approached us, the company already had two other products.
Both of which were outsourced to a Russia-based firm.
Class Act Sports was wildly unsatisfied with the result, having spent four times as much and getting buggy apps in return - in fact, Gunner would end up rewriting Back Attack months later.
Additionally, the sports industry is where we cut our teeth as both of Gunner's partners broke into the industry with ESPN, creating Fantasy and Social apps.
Why was Gunner selected for this project?
Class Act Sports CEO Jared Ginsberg told us he chose Gunner because he could tell "we just got it."
All he needed was to give us the high-level overview, and from there, we fleshed out all the details and added some features he had not even thought of.
Who worked on this project?
What tools, techniques and methodologies were used on this project?