Case Study: Drop Mic IoT

Problem

What was the problem to be solved?

The City of Jupiter, FL had a problem with an upswell in outdoor businesses violating noise ordinances.

Restaurants with outdoor entertainment became vogue in the posh town.

However, these eateries would run afoul of the city ordinances which regulated sound levels at certain times of days.

The city relied on residents to report the violation and these reports were based on conjecture. The residents THINK the noise is too loud.

This meant that the city would have to respond to the complaints and send out a tech who may arrive only to find out the sound levels were within compliance.

At the same time, the businesses also didn’t know if they were in violation so they, too, had to guess at noise levels.

Solution

What was the proposed solution?

Kurtrox proposed a solution that the city jumped on, which was to build devices connected to solar power which could be mounted outside such facilities.

The devices would monitor sound levels and change from green to yellow to red, allowing all parties involved to know if there was a violation.

The businesses would know if there was a violation by looking at the stop-light-like device to see if they were approaching red.

Once the device hit red, the onboard computer would notify the city who would know immediately a violation occurred.

We built the software for Kurtrox’s embedded solution.

Challenges

What challenges arose during the project?

There’s no question this was a tough project.

Converting a raw volume reading into a decibel ratio required us to baseline each device upon deployment.

Over-the-air firmware updates also became a challenge as did the sheer amount of data we had to send via cellular data and also store for historical review.

Technical

What was the technical approach to the project?

Internally, the embedded devices were Beaglebone Blacks that ran off of constant power from a solar panel backed up by a battery.

When the devices came on for the first time, they would use Node.js to capture a baseline and then used this baseline to capture, calculate and broadcast a decibel level every second.

The raw data was stored in AWS S3 buckets where it was streamed via AWS Kinesis and Lambda to DynamoDB and also Athena.

The insertion into DynamoDB tables placed the data in another stream which another Node.js Lambda process handled responding with the acceptance of the reading via a persistent socket (Green, Yellow, Red).

Additionally, if Red, the Lambda function would notify the city via an email sent by AWS SNS and SES.

The entire setup was pretty much headless and serverless relying heavily on AWS IoT.

If the city desired, we could generate ad hoc reports based on device from the time it was first turned on.

Management

What was the project management approach to the project?

Finding the right data plan and device was a huge unknown, so we ended up starting the project with four research sprints to determine the best combination.

After that, we used feature/bug sprints to build a device prototype that could run Node.js.

After we had a functional device prototype, we begin working on a standard sprint schedule until release:

1) One week function sprint where we added new functionality

2) One week QA sprint

3) One week bug fix sprint

Repeat until finished.

Lessons

What did you learn from working on this project?

We learned a lot about Big Data – especially in conjunction with AWS.

We have worked on projects with tons of data, but this one exceeded all the others.

Also, we learned how to use persistent web sockets via IoT to communicate with the remote devices.

Why Gunner?

Why was Gunner selected for this project?

Kurtrox had worked with Gunner on a number of IoT projects so there was a built-in familiarity here.

Kurtox also had offices located close to Gunner, which made collaboration relatively easy.

Case Study: Shudi Mobile App

Problem

What was the problem to be solved?

Matt is an active duty serviceman and entrepreneur who created an idea to crowdsource decision making via a social platform.

The idea was to allow users to post simple, binary items such as “Which one should I get for lunch?”, including a photo of each item.

The app alerts other Shudi users about the post and places it in a global feed for all users to see.

Users can then vote for which option they suggest and comment to tell the creator why they voted the way they did.

Solution

What was the proposed solution?

Working with a tight budget, we approached this project from a standpoint of “What is the minimum viable project that is fun, useful and exhibits the potential of the app?”

We encouraged Matt to look at this as a showcase prototype that we could take to investors who could provide the resources needed to expand Shudi into mass adoption.

This meant prioritizing features based on impact and simplicity. Anything that wasn’t core to the idea and required a lot of time was pushed to future development.

Challenges

What challenges arose during the project?

First, Matt had a small budget – which was no fault of his.

Unfortunately, he original had taken his idea overseas for outsourced development.

As is almost always the case, this didn’t end well as Matt exhausted most of his budget and got back a non-functional app.

We examined the code and nearly all of it was not reusable.

As mentioned, we solved this problem by focusing on an MVP and also by moving from Swift to React Native which allowed for more rapid development.

Second, Matt was deployed in South Korea, so communication was almost non-existent.

To solve this problem, we laid out a detailed roadmap after the research sprint and provided him recorded, video demos after each sprint.

Finally, we were on a compressed timeline as competitors such as Facebook and Instagram appeared to be entering the market.

React Native helped here as well because it allowed us to simultaneously build the Android and iOS apps.

Technical

What was the technical approach to the project?

As touched upon, React Native was the backbone of our stack choice.

Specifically, we chose Apollo with GraphQL for our API bridge and Material Design as our design framework.

We built out the supporting backend using a plethora of AWS technologies, including Mobile Hub (for configuration management), AppSync (for API Management), DynamoDB (for data management), Lambda (for task management), Pinpoint (for analytics management), SNS/SES (for syndication management), Cognito (for authentication and account management) and more.

Management

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.

Matt had previously had screens mocked up for Shudi, but those needed to be revised.

Because communication was difficult, we were left to our own assumptions a lot of the time, so we started with a two-week research sprint, followed by two feature sprints, a bug sprint and then two feature sprints until the project was completed.

Lessons

What did you learn from working on this project?

We learned a lot about AWS Cognito during this project – specifically, integrating it with callback hooks during registration to validate certain things about the sign up.

We had custom parameters that needed to be checked that weren’t a standard part of Cognito, so we had to implement custom logic in Lambda and hook it into the registration process.

Why Gunner?

Why was Gunner selected for this project?

Gunner had the unique ability to focus on what was important to manage budget and time constraints while still creating a fun application which definitely highlights Shudi’s potential.

Gunner provided valuable business process insights as well, helping to create a plan to get from prototype to investment.

Architectural Description

What platform was built for this project?

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.

 

Case Study: RadPad

 

Client Name

RadPad

Industry

Real Estate

Problem Summary

RadPad is an end-to-end rental marketplace focused around people. Renters use RadPad to find a place, sign their lease and pay rent. Landlords use RadPad to list places, sign leases electronically and accept rents.

Jonathan Eppers, Tyler Galpin and Tim Watson founded RadPad in 2012 after attempting to find an apartment in Los Angeles proved to be a terrible experience.

Development began in July 2012 in Venice, California, and was released to friends on Facebook in October.

In January 2013, RadPad had reached over 10,000 downloads and was invited to join the startup accelerator Amplify.LA.

It was around this time that RadPad realized it had a scalability problem – both in terms of listings scraping and traffic through the app.

As a startup, RadPad needed an infrastructure that was highly available, redundant, secure and would automatically scale without human intervention.

And it needed to be done on a minimal budget.

Solution Summary

Gunner Technology proposed to move RadPad’s infrastructure to Heroku a Platform-as-a-Solution that was relatively easy to use and could be configured as part of the development process.

Challenges

The biggest challenge was getting the memory footprint of the application down.

We inherited a Ruby on Rails application running Mongrels that consumed way more memory than the, at the time, allowable 512 mb on Heroku.

The app leaked like a sieve, too.

To combat this in the short term, we migrated to Unicorn application servers instead of Mongrel and used NewRelic to knock off some low-hanging fruit in terms of memory consumption.

We then wrote a script that would constantly monitor and kill Unicorn instances as they approached 100% memory usage.

Long term, we tracked down the leaks and optimized those as well.

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)
Heroku allowed us to script deployments and easily clone the production environment for staging and demonstration purposes.

We could also run background dynos that would automatically increase in number to parse rental listings from various sources and replicate the data to our Postgres Database.

If, for example, there were thousands of listings to process, we could run 20 dynos and parse the listings in minutes and then scale back down to a single dyno.

This allowed us to keep cost low as we were only billed for the hours the dynos we running.

We did something similar on the front end to handle spikes in traffic which were occurring frequently as RadPad had begun to be featured in trade blogs and news media.

Project Management Approach

This was a trail-by-fire project as RadPad was an existing app with growing demand that needed fixing asap.

We attempted to run an agile approach, but ended up having to put out a lot of fires mid-sprint on the existing infrastructure while working on migrating to the new infrastructure.

We had at least one on-call engineer 24/7 who handled the fires while the other engineer worked on the stories in each one-week sprint.

Project Roles

Dary Merckens – Engineer

Cody Swann – Engineer

Proficiencies Used

  • agile
  • availability
  • AWS
  • AWS Availability Zones
  • AWS Regions
  • backend
  • Bug Sprint
  • Continuous Deployment
  • deploy
  • DevOps
  • disaster recovery
  • distributed service
  • Postgres
  • Feature Sprint
  • functional requirements
  • git
  • immutable
  • iteration
  • iterative
  • Ruby
  • Ruby on Rails
  • non-functional requirements
  • NoSQL
  • NOTS
  • production
  • Redundancy
  • research sprint
  • S3
  • scalability
  • serverless
  • sprint
  • technical requirements
  • the cloud
  • Tolerant
  • uptime
  • version control
  • Heroku

Lessons Learned

What did you learn from this project or when overcoming the challenges?
In this project, we learned the value of monitoring apps like New Relic and how invaluable they can be when trying to chase down memory issues.

Benefits

After the migration, RadPad no longer had a scalability issue and managed 99.999% uptime.

Additionally, while usage increased over 1,000%, cost only increased by 32%.

Why Gunner Technology?

While at ESPN, Dary and Cody had migrated a large social network to Heroku when the platform was still young.

That gave us the expertise necessary for tackling this project while under fire.

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

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

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

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