Class Act Sports, LLC
Sports and Entertainment
Describe why the project / work needed to be done (what problem needed solving?) in the most non technical format possible (Good Question for the Client/Stake Holder to answer)
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.
For example, if you picked the Patriots to beat the Falcons in Week 1, you could not pick the Patriots for any other games in that season.
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.
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.
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.
Here you will describe the software stack used in the project and why it is the best stack for the job. (Good Question for Gunner to answer)
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.
So our solution was to build an app on AWS AppSync and Serverless framework using React, React Native and GraphQL.
The web app version was built using React while the mobile version was build using React Native.
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.
We went with Material UI as the design framework which provided a solid foundation for both the native platforms and browsers.
Finally, we used PayPal as our payment processor.
Explain what form of project management was used (Waterfall, Hybrid, Agile (Scrum, extreme, etc)), why it was chosen and specifics, such as length of iteration. (Good Question for both to answer)
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.
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.
Before the project, this is a projected estimation of what we see as the benefits to completing the works, including specifics, if possible. Instead of “decrease in expenses and an increases in revenue,” something like, we forecast that labor costs will fall by as much as 10% while online revenue will increase by 5%. After the project, same thing, but with real numbers (Good Question for both to answer)
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.
This would be a good place for a client quote AFTER the project is completed (mixed with some of our own comments). Before the project, this is just a quick summary of why Gunner Technology is the best firm to do this work. (Good Question for both to answer)
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.
Also, our Serverless Stack with React and React Native allowed us to commit to the tight timeline and stay under budget.
Describe the architecture and why it was chosen (uptime, disaster recovery, etc)
We chose a serverless architecture because it provides the perfect combination of scalability and cost.
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.