Case Study: John’s Island Real Estate Salesforce Integration

Client Name

Johns Island Real Estate

Industry

Real Estate

Budget/Compensation

$20,000

Problem Summary

JIRE purchased a subscription to PropertyBase, which is Salesforce’s real estate plugin.

Unfortunately, the model of integration Saleforce had in mind (where the website would be generated from their end) turned out be unfeasible.

Solution Summary

Gunner proposed using the Salesforce API to push data from the open source CRM to Salesforce and maintain the existing platform.

This would give JIRE the flexibility it needed from a product standpoint while still feeding the data into PropertyBase, which would keep the CRM functionality they desired in the first place.

Challenges

PropertyBase turned out to be more of a bolted on afterthought than a first-class citizen in the Salesforce world.

That meant, once JIRE was under contract, we didn’t get much support help and were left figuring out how to integrate with the Salesforce API on our own.

Testing was also a challenge because JIRE didn’t have a test environment for PropertyBase and couldn’t always tell if the data was correct.

Technical Approach

Simply put – we needed to keep the data in sync between the two platforms.

We did this using AWS JavaScript-based Lambda functions behind AWS API Gateway.

Whenever a listing was saved on the JIRE platform, the Ruby on Rails application would notify the serverless API which would create an entry in an SQS queue.

That queue was connected to another lambda function which grabbed the current data in Salesforce using the Salesforce API and munged it with the new data in the queue.

The resulting data was then sent to PropertyBase via the Salesforce API, updating the data on their end.

Project Management Approach

As with most projects, we took an Agile Scrum approach.

Half of this project were research sprints and only two were implementation sprints.

The infrastructure and code setup was relatively easy.

What took the most time was testing and matching data.

JIRE didn’t know exactly what they wanted synced to what.

For example, the JIRE platform had a concept of Property Type while Salesforce had Features.

These discrepancies weren’t one-to-one mappings, so we had to work with JIRE to come up with business rules for mapping the data.

Then, it was difficult to tell if a sync failed because the JIRE team would make updates to the JIRE data and forget to check to see if the sync was correct on the PropertyBase side.

Then, someone might come in and edit PropertyBase and we wouldn’t know what happened – was the sync wrong or did someone change the data manually?

Project Roles

Solutions Architect – Cody Swann

Web Developer – Cody Swann

Project Manager – Lisa Brignac

Proficiencies Used

  • Ruby
  • Ruby on Rails
  • JavaScript
  • Salesforce
  • PropertyBase
  • Lambda
  • API Gateway
  • Serverless
  • SQS
  • AWS
  • Elastic Beanstalk
  • Agile
  • Scrum
  • Continuous Deployment
  • Continuous Development
  • Git

Lessons Learned

We’ve worked with Salesforce a lot, but this was our first time with PropertyBase.

This taught us that not all Salesforce products are created – or treated – equally.

Benefits

After the project’s launch, JIRE was able to use a single source of data while still leveraging the benefits of PropetyBase.

Why Gunner Technology?

Gunner has worked extensively with the Salesforce API, so we were immediately familiar with how to get up and running, so we put together a demo for JIRE that illustrated our proficiency with Salesforce.

Case Study: Performance Unlimited

Client Name

Pittsburgh Pirates

Industry

Sports and Athletics

Budget/Compensation

$90,000

Problem Summary

The Pittsburgh Pirates wanted to give their strength and conditioning staff a way to track, measure and correlate qualitative and quantitative data to their athlete’s on-field performance.

For example, they wanted to see if their training regimen and guidance translated to on-field performance.

Solution Summary

Gunner Technology proposed a Progressive Web App that could be used by trainers, managers and players.

General Managers, for example, would have an admin level, read-only look into the data with the ability to create graphs and charts.

The trainers could create qualitative questionnaires such as recovery survey which would rank players based on their answers to the questions.

For example, a player who answers “A” on the question: How many of hours of sleep did you get last night?

A) 7 or more
B) 5-7
C) 3-5
D) Less than 3

Would get four points (3 for B, 1 for C and 0 for D).

The trainers could customize the scoring and create as many surveys as they wanted.

The players could take these on their own, or the trainers could enter responses for them.

Similarly, the app would allow the trainers to enter players training data such as 40 yard dash time and bench press numbers.

We would then built a back-end parser that would consume data from Stats, Inc and tie it to each player.

Challenges

The main challenge was coming up with a clean UI that would allow players and trainers to fill in the information extremely quickly.

The players are not happy about any extra work so any sort of impediment would irritate them.

Also, it was a somewhat political balance because we were potentially hurting the trainers who we were working with to build the application.

What if there was no correlation between their advice and performance? Or worse – an inverse correlation.

Finally, this was in the early days of PWAs so getting the app to function in areas without data reception was tricky.

Technical Approach

We went with a PWA because the app needed to function on a slew of different devices. Desktops, laptops, projectors, TV screens, phones, tablets, etc.

For design, we used the Bootstrap UI framework which we used to provide a user experience similar to Twitter and we also built-out a leaderboard to entice the players into wanting to do the surveys to compete with one another.

On the backend, we went serverless with node AWS Lambda, DynamoDB and Kinesis.

We relied on the open source D3 JavaScript library to generate the charts and graphs.

Project Management Approach *

We took an Agile Scrum approach to this project with two, one-week research sprints to start the project followed by development sprints until completion.

Each development iteration lasted a week and was followed by a demo to stakeholders who offered consistent feedback and guidance.

Project Roles

Cody Swann – Project Manager

Cody Swann – Solutions Architect

Dary Merckens – Front End Developer

Dary Merckens – Back End Developer

Proficiencies Used

  • Kinesis
  • AWS
  • Lambda
  • Serverless
  • DynamoDB
  • Agile
  • JavaScript
  • PWA
  • Service Workers
  • Bootstrap
  • CSS
  • HTML
  • Agile
  • Scrum
  • Continuous Deployment
  • Continuous Development
  • Git
  • Node
  • D3

Lessons Learned

The stakeholders were some of the best we’ve had.

They bought into the agile process even though they were knew to it and were involved every step of the way.

They understood cost-implications of feature requests and how to balance good-enough vs perfection.

We really learned from this the importance of getting buy-in from the client with your project management approach.

Benefits

We are under agreement to not share the results of the application, but, let’s just say we wouldn’t mind if you took a look at their record before and after the launch of the platform.

Why Gunner Technology?

The Pirates were intrigued by our experience at ESPN.

Also, as former athletes, we were able to communicate with the client and understand the requirements right away.

To seal the deal, we offered them two weeks of free development to showcase what we can accomplish.

Project Screenshots

performanceunlimited (1) - Cody Swann.png

Architectural Diagram

JustGivingImage1a - Cody Swann.PNG

 

Case Study: eCapture

Client Name

Palm Beach Broadcasting, LLC

Industry

Marketing, Sports and Entertainment

Budget/Compensation

$20,000

Problem Summary

Palm Beach Broadcasting, LLC owns and operates radio stations in Palm Beach County.

The company broadcasts music and entertainment, as well as information on local news, traffic, and weather.

It also offers listeners and advertisers with local marketing resources, as well as provides advertising and marketing opportunities.

The company was founded in 2002 and is based in West Palm Beach, Florida. Palm Beach Broadcasting, LLC operates as a subsidiary of Digity, LLC.

One thing all the radio stations owned by PBB does is event marketing; often in the parking lots of country music concerts and other similar type events.

The common thread among these venues is the volume of foot traffic, which often renders cell data useless.

This presented a problem for PBB which wanted to collect email addresses for marketing purposes electronically, but had no way to save them.

Instead, they reverted to pen and paper signup forms, which were difficult to read and required manual entry after the event; not to mention they were not environmentally friendly.

Solution Summary

Gunner Technology rep encountered a PBB-owned station doing this at a concert and proposed a solution, which was to build an offline-capable app which could run on any Android or iOS device (phone or tablet).

The device would store the data on the physical device until it could get data reception and then it would sync the data to a central repository where all their marketing emails were kept.

Challenges

Fortunately, AWS AppSync makes most of the nitty-gritty of this very easy. The one challenge was building the app so that it could be skinned by an administrator quickly and without an account.

At any given event, the promotion may be co-branded, so the radio station may need to re-skin the app to include the logo of the other company and potentially change the opt-in text.

Technical Approach

This project was tailored for AWS AppSyc.

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.

We use AWS AppSync to build native mobile and web apps with iOS, Android, JavaScript and React Native.

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.

Project Management Approach

We started out with nothing (no mocks, no wireframes, etc), so we started with 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.

After we had a UI 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.

Project Roles

Lisa Brignac – Project Manager

Keith Cohn – Designer

Cody Swann – Front-end Engineer

Dary Merckens – Backend Engineer

Proficiencies Used

  • agile
  • Android
  • API
  • API Gateway
  • Apollo
  • AppSync
  • availability
  • AWS
  • AWS Availability Zones
  • AWS Regions
  • backend
  • Bug Sprint
  • CodeCommit
  • Cognito
  • Continuous Deployment
  • CSS
  • deploy
  • Design Framework
  • DevOps
  • disaster recovery
  • distributed service
  • DynamoDB
  • ES6
  • Feature Sprint
  • frontend
  • functional design
  • functional requirements
  • git
  • Graphql
  • HTML
  • immutable
  • iOS
  • iteration
  • iterative
  • JavaScript
  • Lambda
  • Material Design
  • Mobile Hub
  • native app
  • Node
  • non-functional requirements
  • NoSQL
  • NOTS
  • production
  • React
  • react native
  • Redundancy
  • research sprint
  • RxJS
  • S3
  • scalability
  • SDK
  • serverless
  • Serverless Framework
  • sprint
  • technical requirements
  • the cloud
  • Tolerant
  • uptime
  • version control
  • fastlane

Lessons Learned

This was an extremely compressed deadline, so we learned the importance of streamlined deployments which is why this is the first project we integrated Fastlane with Fabric and Testflight for automated builds and deploys to QA.

Benefits

PBB has deployed the app to all of their radio stations and has been able to save roughly 10 hours a week they previously spent on data entry.

Additionally, they save roughly $200 per event on print costs and have reduced their carbon footprint significantly.

Why Gunner Technology?

PBB didn’t even know this was possible until Gunner suggested it, so we had a pretty good inside track to getting the gig.

That said, we had done similar work in marketing for Country Shore so we had some case studies to show PBB as illustrations

Project Screenshots

0x0ss - Cody Swann0x0ss (3) - Cody Swann0x0ss (4) - Cody Swann0x0ss (1) - Cody Swann0x0ss (2) - Cody Swann

Architectural Description

GraphQL Proxy

A component that runs the GraphQL engine for processing requests and mapping them to logical functions for data operations or triggers. The data resolution process performs a batching process (called the Data Loader) to your data sources. This component also manages conflict detection and resolution strategies.

Operation

AWS AppSync supports the three GraphQL operations: query (read-only fetch), mutation (write followed by a fetch), and subscription (long-lived requests that receive data in response to events).

Action

There is one action that AWS AppSync defines. This action is a notification to connected subscribers, which is the result of a mutation. Clients become subscribers through a handshake process following a GraphQL subscription.

Data Source

A persistent storage system or a trigger, along with credentials for accessing that system or trigger. Your application state is managed by the system or trigger defined in a data source.

Resolver

A function that converts the GraphQL payload to the underlying storage system protocol and executes if the caller is authorized to invoke it. Resolvers are comprised of request and response mapping templates, which contain transformation and execution logic.

Identity

A representation of the caller based on a set of credentials, which must be sent along with every request to the GraphQL proxy. It includes permissions to invoke resolvers. Identity information is also passed as context to a resolver and the conflict handler to perform additional checks.

AWS AppSync Client

The location where GraphQL operations are defined. The client performs appropriate authorization wrapping of request statements before submitting to the GraphQL proxy. Responses are persisted in an offline store and mutations are made in a write-through pattern.

Architecture Diagram

1_E1KwFeH3ahexWaHVFIFuow (1) - Cody Swann

Case Study: iPolish & iArmor

Client Name

Biltmore Technologies

Industry

Consumer Electronics

Start Date

09/01/2013

Target Launch Date

01/01/2015

Actual Launch Date

01/01/2015

Budget/Compensation

$180,000

Problem Summary

Biltmore Technologies acquired the patents for color-changing nano-technologies via flexible polymers and needed a way to demonstrate the capabilities of the technology, so they created the idea for color-changing nails that could be controlled via an iPhone.

Biltmore needed a company that could build an iPhone app that could communicate with the polymers.

Biltmore Technologies retained Gunner Technology to build a complete hardware and software solution that would allow on-demand control over the opacity and color of consumer products such as fingernails, vehicles, sunglasses and more via Bluetooth Low Energy.

Specifically, iPolish would be a consumer product that allowed purchasers to apply clear coated press-on nails, which they could then change the color of using their iPhone.

Similarly, iArmor was to be a consumer product for homes and automobiles to control tint and privacy by changing the opacity of glass via an iPhone app.

Solution Summary

Gunner Technology proposed using the Bluetooth Low Energy API on the iPhone SDK to communicate to a customized “wand” which would in turn communicate with the substrates on the polymers.

Challenges

In this section, you’re going to explain any challenges that were faced or are anticipated to be faced – such as tight deadlines, iterations with unknowns, etc. Also include how you plan to or did overcome these challenges (Good Question for both Client/Stake Holder and Gunner to answer)

Where to begin.

This was something that had never been done before so we had to figure out a number of things.

First thing was fingering out how to develop a custom color picker that limited the colors to that which the substrate/polymers would allow.

Second, we had to solve the challenge of converting an RGB value on a back-lit screen to a CMYK value on a real-world, front-lit object (the nail).

Finally, we had to figure out how to communicate to the wand using BLE.

Technical Approach

Most of this work was all front end, however, there was a back-end component of this as well and that involved saving preferences and authentication.

For this, we used node.js with a Mongo database.

Project Management Approach

We took an Agile Scrum approach to this project with many research sprints.

We kicked the project off with a research sprint and then held development sprints until we ran out of knowledge and had to have another research sprint.

Our iterations were one-week long each and all development sprints ended with a product demonstration via a potentially launchable product

Project Roles

  • Cody Swann – Engineer
  • Dary Merckens – Front-end Developer
  • Cody Swann – Backend Developer
  • Lisa Brignac – Project manager

Proficiencies Used

  • BLE
  • Node
  • Mongo
  • Research Sprint
  • Development Sprint
  • Agile
  • Potentially Launchable Product
  • JavaScript
  • Iteration
  • IPM
  • Swift

Lessons Learned

We learned so much about BLE and also the mathematics behind color – especially the difference between the additive color model and the subtractive color model and converting between the two.

Benefits

Unfortunately, Biltmore could never figure out how to make the substrates last in direct sunlight so the nail polish idea never took off.

However, Biltmore was able to use iPolish as a demonstration that raised capital for the company from investors including Dean Woodman.

Why Gunner Technology?

Gunner was one of the first companies to have production Swift applications in the wild and we used it to quickly write up a demo for Biltmore to illustrate our vision.

This show-and-tell was enough to convince Biltmore to go with us.

Project Screenshots

ipolish - Cody Swann

Case Study: Talk It Out encrypted messaging

Client Name

Undisclosed

Industry

Communication

Start Date

04/01/2017

Target Launch Date

05/01/2017

Actual Launch Date

05/01/2017

Budget/Compensation

$10,000

Problem Summary

Our client was in an industry that involved recruiting employees from other firms.

It was a sensitive process and we were required to sign an strict NDA to tackle the project.

Because of the sensitive nature of the communications, our client wanted to have a way that there would be no trace of the communication and would not require the other party to install an application.

Solution Summary

Describe our solution / approach to the work that needs to be solved / done – again in non-technical terms (Good Question for Gunner to answer)
We proposed a completely serverless approach that would leverage web sockets and embeddable JavaScript.

Neither party would be required to create an account, however, each link to the embedded JavaScript would require a secret URL, handle and password.

Additionally, the initiator of the conversation would choose a secret key which would be used to encrypt the conversation at rest.

The key would need to be communicated verbally and the other party would have to unlock the room with the key.

The messages would be sent – encrypted – over SSL sockets directly to the other recipient.

Challenges

The only challenge we encountered was how to do serverless sockets.

After some investigating, we discovered it could be done using AWS IoT even though that was not the originally intended purpose of the technology.

Technical Approach

We used RxJS on the client side to stream the data to a Lambda function after authenticating with AWS cognito.

The Lambda function simply passed the message as is to the other client where the message was unencrypted using the shared code word.

The two endpoints didn’t even need to be on remote servers. A local HTML file that included the necessary scripts could be used as a client.

Project Management Approach

We had just over 30 days to complete this project, so it was a mad scramble with only a single resource dedicated to the project.

Unfortunately, serverless websockets was a big unknown for us, so it took us two research sprints to find a solution.

After that, we followed with two feature sprints and a bug sprint and launched right on time.

Project Roles

  • Cody Swann – Project Manager
  • Cody Swann – Web Developer

Proficiencies Used

  • agile
  • API
  • API Gateway
  • availability
  • AWS
  • AWS Availability Zones
  • AWS Regions
  • backend
  • Bug Sprint
  • CodeCommit
  • Continuous Deployment
  • CSS
  • deploy
  • Design Framework
  • DevOps
  • disaster recovery
  • distributed service
  • DynamoDB
  • ES6
  • Feature Sprint
  • frontend
  • functional requirements
  • git
  • HTML
  • immutable
  • iteration
  • iterative
  • JavaScript
  • Lambda
  • Node
  • non-functional requirements
  • NoSQL
  • NOTS
  • production
  • Redundancy
  • research sprint
  • RxJS
  • S3
  • scalability
  • SDK
  • serverless
  • Serverless Framework
  • sprint
  • technical requirements
  • the cloud
  • Tolerant
  • uptime
  • version control
  • AWS IoT
  • IoT

Lessons Learned

We learned that completely serverless web sockets are a work in progress and you need to get creative to implement them.

Benefits

We’re not allowed to give away specific usage statistics of the app, but the firm continues to use this product today.

Why Gunner Technology?

The firm was attracted to our experience with HIPAA and loved our proposed solution because it would not require any installation and we provided a functional demo with our proposal.

Project Screenshots

talkitout-3 - Cody Swanntalkitout-4 - Cody Swanntalkitout-2 - Cody Swanntalkitout-1 - Cody Swann

Architectural Diagram

aws-diagram - Cody Swann

Case Study: Country Shore Marketing Automation

Client Name

Country Shore

Industry

Retail

Project Title

Marketing Automation

Start Date

01/01/2015

Target Launch Date

03/01/2015

Actual Launch Date

03/01/2015

Budget/Compensation

Revenue Shares from Sales

Problem Summary

As a small company that was hugely reliant on Internet sales, digital marketing was crucial for Country Shore.

However, at the time, the tools that were offered by ad platforms such as Google AdWords and Facebook Ads were not 100% sufficient.

Often Country Shore would hit spending limits on one part of their marketing funnel on a particular day even though the ROI from that channel was providing immediate and significant revenue.

For example, if Country Shore ran a remarketing ad that cost $5.00 per click with a maximum spend of $500 per day, but it was generating sales of $50 while only costing $20 per sale, they would be leaving money on the table.

Solution Summary

The solution Gunner came up with was to generate real-time ROI on each stage of the funnel.

As long as the ROI was positive, the cap should continually be raised.

However, if the ROI was negative, once the cap is reached, the ad should stop running for that day.

Challenges

The main challenge was coordinating all the APIs.

We basically needed to constantly generate the ROI on all the different ads by pulling data from the Shopify API and comparing it to the data from the ads and decide if the ad should keep running or get shutdown.

Technical Approach

We leverage AWS Lambda to create a lot of microservices in the open source serverless framework.

Each microservice had one purpose – check ad spend, check sales from ad, update ad, etc, etc.

In all, we coordinated APIs between Shopify, AdWords and Facebook Ads.

Project Management Approach

We took an Agile Scrum approach to the project with one-week iterations and an IPM each week to demonstrate our progress.

We started with one research sprint to learn about the AdWords and Facebook Ads APIs, and after that, we worked in development sprints until completion.

Project Roles

Lisa Brignac – Project Manager

Cody Swann – Developer

Proficiencies Used

  • Shopify
  • e-commerce
  • Microservices
  • AWS
  • Lambda
  • JavaScript
  • Node
  • Ruby on Rails
  • serverless framework
  • serverless
  • Facebook Ads
  • Google AdWords
  • APIs

Lessons Learned

We learned a lot about the AdWords and Facebook Ads APIs.

We also learned how to streamline and scale requests between the services so we would not hit throttle limits.

Benefits

At the end of the day, we implemented a solution that captured all available net positive revenue.

We kept spending, tweaked CPC and adjusted caps to capture all positive value.

This meant that we generated as much revenue as possible, which was Country Shore’s goal at the time.

The algorithm’s were all configurable, too. Meaning Country Shore could say “instead of positive ROI, run the ads until they dip below 10% ROI.”

This would be the change to make if profit margins became more important than straight revenue.

In the end, Country Shore saw revenue increase from online sales by 20%

Why Gunner Technology?

Gunner Technology has had a long-standing relationship with Country Shore as we helped set up their entire technology infrastructure when the company launched and are constantly automating redundant tasks for them.

Architectural Diagram

Country Shore - Marketing Automation - Cody Swann.png

Architectural Description

The infrastructure was completely headless.

We used serverless framework to organize and coordinate the microservices and simply created Node Lambda functions that ran on a given schedule (every minute).

Case Study: Class Act Survivor App

Client Name

Class Act Sports, LLC

Industry

Sports and Entertainment

Start Date

06/01/2016

Target Launch Date

09/01/2016

Actual Launch Date

09/01/2016

Budget/Compensation

$40,000

Problem Summary

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.

Solution Summary

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.

Challenges

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.

Technical Approach

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.

Project Management Approach

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.

Project Roles

  • Lisa Brignac – Project Manager
  • Keith Cohn – Designer
  • Cody Swann – Front-end Engineer
  • Dary Merckens – Backend Engineer

Proficiencies Used

  • agile
  • Android
  • API
  • API Gateway
  • Apollo
  • AppSync
  • availability
  • AWS
  • AWS Availability Zones
  • AWS Regions
  • backend
  • Bug Sprint
  • CDN
  • Cloudfront
  • CodeCommit
  • Cognito
  • Continous Deployment
  • CSS
  • deploy
  • Design Framework
  • DevOps
  • disaster recovery
  • distributed service
  • DynamoDB
  • ES6
  • Feature Sprint
  • frontend
  • functional design
  • functional requirements
  • git
  • Graphql
  • HTML
  • immutable
  • iOS
  • iteration
  • iterative
  • JavaScript
  • Lambda
  • Material Design
  • Mobile Hub
  • native app
  • Node
  • non-functional requirements
  • NoSQL
  • NOTS
  • Pinpoint
  • production
  • React
  • react native
  • Redundancy
  • research sprint
  • RxJS
  • S3
  • scalability
  • SDK
  • serverless
  • Serverless Framework
  • SES
  • SNS
  • sprint
  • SQS
  • Staff Augmentation
  • technical requirements
  • the cloud
  • Tolerant
  • uptime
  • version control

Lessons Learned

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.

Benefits

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.

Why Gunner Technology?

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.

Architectural Description

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.

We use AWS AppSync to build native mobile and web apps with iOS, Android, JavaScript and React Native.

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.

Architectural Diagram

1_E1KwFeH3ahexWaHVFIFuow - Cody Swann.png

Project Screenshots

classactsurvivor-2 - Cody Swann.png

classactsurvivor-1 - Cody Swann.png

classactsurvivor-3 - Cody Swann.png