Proximity Grid is a startup developing a location based bookmarking app, GridSnap, that allows users to explore, record, and engage with points of interest in the world around them. The app is built around the concept of a Grid Card which represents a place or object in the physical world and allows users to quickly connect with this place/thing. Users can create cards, by taking a photo, recording a sound clip, or selecting it on a map. Additional content for the item is then pulled from data sources like Google Places and Foursquare to populate a set of initial attributes for the card (e.g. name, address, phone number, description, etc). Users are able to manage and organize their cards into various collections, allowing them to quickly and easily find and engage with their previous points of interest.
I was brought into the Proximity Grid team to provide backend architecture, development, and maintenance support. The original author of the system had previously departed and the backend service was being maintained by the iOS engineers developing the associated mobile app. Built on the Yii PHP framework, the system showed signs of general neglect, with very little documentation, no test coverage, limited logging/monitoring, a single production server, and a significant amount of dead code.
The following are a few of the initiatives I helped deliver for the team after getting ramped up on the system in general:
Production Environment Rebuild: When I got started, the production backend service was run entirely on a single EC2 instance, including the web server, all document storage, a MySQL instance, and a MongoDB instance, and this was the only supported environment for the platform. This immediately raised concerns for myself and the team as a whole. In addition to the reliability risks associated with this setup, without a separate QA environment we were unable to effectively validate our work, prior to production deployments. In light of this, I rebuilt the production environment from scratch, capturing an EC2 AMI for the instance to allow us to quickly and easily scale up or down as needed and documenting the steps required to set up this instance for posterity. I provisioned two application server instances and configured an ELB to route traffic to both instances. I also migrated all document storage (e.g. sound clips, images, etc) to an S3 bucket and moved both databases to an appropriate managed service provider, using RDS for the MySQL instance and Atlas for the MongoDB cluster. Once this was completed I set up a single instance QA environment with reduced capacity instances.
Notifications: As part of a campaign to address additional use cases, we added the ability to schedule and trigger notifications on a Grid Card (e.g. "Remind me to return here in 6 months to purchase an anniversary gift for my wife."). In order to support this functionality, I updated the Grid Card API and data model to capture this information, set up a scheduled background worker to monitor for and trigger each notification as it's scheduled time is reached, and integrated directly into the APNS services for both production and test/development environments to deliver the notification to the associated user.
Web Application: Initially the platform supported a single iOS mobile app as it's only consumer. As we prepared to launch the product to our initial set of target users the value of supporting a web interface increased dramatically. This would serve as a channel for attracting new users, demonstrating the value of the platform, and then converting them to app users to unlock additional functionality. I was able to quickly develop a React web app reusing the same APIs as those used by the mobile app. This app supported the core set of read-only capabilities within the platform, which included rendering all static content for the card (e.g. title, description, images, etc), displaying an embedded streetview for the associated location, integrating with Google Directions API to calculate the distance from the user's current location, rendering one-click buttons to load navigation directions from Google Maps or Apple Maps, integration with speech synthesis libraries to allow sections of the card to be read aloud, etc. Overall the capabilities of the web app provided quick and easy access to the content available within the platform and it did a great job generating interest in users that weren't initially willing to install the app.
Development Process: The team initially consisted of myself, two other remote engineers, and the founder and CEO of the business. After working with team for a few weeks it became clear that the efficiency of the team was suffering due to a lack of consistent direction and process. I stepped in to fill this gap on an interim basis as we sought to find a dedicated product manager. I started by refining the existing Scrum-based process in use by the team, establishing daily standup meetings, regular backlog grooming and sprint kickoff meetings, and a process for the submission and refinement of new features into the backlog. While this resulted in a noticeable improvement in the quality and speed of work produced by the team, we struggled to keep the scope of each sprint fixed due to frequently changing priorities. To align our engineering process to this reality, we migrated to Kanban as our overarching process, allowing us to adapt more fluidly to the frequent changes in direction. This significantly reduced the overhead incurred within the engineering team and reduced friction between the engineering team and the business leadership.
After iterating through a number of target use cases, the company struggled to find and focus on a single audience. As a result the app has not gained traction nor grown a significant user base. I continue to serve as an advisor, providing feedback and guidance as requested, but have generally shifted my focus onto other projects.