SpiderDoor

SOFTWARE DEVELOPMENT
SpiderDoor platform

SpiderDoor is a self-storage project that extends management software by adding a variety of services such as Text Collector, keypads integration, push/text notification and mobile apps that allow tenants to manage their units.

Self-storage facility management

Self-storage business has a whole lot of problems that are waiting to be solved by a smart software. The typical flow of a storage facility requires managers to take account of units and tenants responsible for the goods stored in those units, charges for these units, debts and advance payments. The managers should also let the tenants in and out, control access to different buildings, lock units in case the tenant's payment is overdue, remove the lock when the tenant pays the dues, fix doors or other equipment and so on. Storages can be quite big - sometimes managers can spend the whole day running across the location locking and unlocking the doors.

Storage management has a lot of work related to accounting and record keeping. There is a bunch of web services that facilitate accounting designed specially for this business. The initial idea of the SpiderDoor project was to deal with a variety of these systems by consuming their APIs. The project owner wanted the collected data to be provided through a common interface to mobile apps with user-friendly features missing in the original "dry" management software.

The story

The SpiderDoor project was started in September 2016 by Aaron Harwell, the owner of Safeguard Storage location in Trussville, Alabama. Aaron started this ambitious project with a small development company called Blue Whale Apps Development whose developers were connected with Anadea through our collaboration with Zillow. Over a few months the project grew up and Blue Whale managers decided they would need a solid back-end engineer as their engineers were more proficient in mobile development than in Ruby on Rails. So, they contacted our company and asked for a Rails engineer specialized in third-party integration and database optimization.

This is how our software developer Vadim Kondratiev became the lead developer in SpiderDoor. Other Anadea engineers who participated in the project from time to time were Eugene Grechuk and Roman Firsov.

The project changeover took a few months. Vadim started with covering the code base by all types of automated tests (at the moment the back-end is covered by more than 600 automated use cases that take less than a minute to pass) and refactoring the database structure. Then he moved the third-party services integration to the background and switched it from real-time API calls to a subtle synchronization that was pulling all data from the management software into SpiderDoor database before using it in the app flow. This allowed of reducing the number of API calls to ~250 calls per day in each location and increasing the mobile API response speed from 4-8 seconds to 30 milliseconds.

  • SpiderDoor web - choose location
  • SpiderDoor web - location details
  • SpiderDoor web - tenant information

This was a foundation for further solutions that facilitated daily routines in self-storage locations and attracted more storage owners to SpiderDoor.

Self-storage APIs and mobile apps development

The services integrated in the first place were QuikStor, DoorSwap, StorageCommander and SiteLink. In order to implement all features the project owner wanted to implement, we had to literally suck all the data out of the self-storage management software. For this purpose, we have designed and developed a sophisticated background synchronization schedule. This mechanism was aggregating the data and storing in the internal database for further development of unique features. The features appeared to be so highly demanded that SpiderDoor even got to the list of SiteLink partners.

The common interface to multiple web services allowed us to develop products SiteLink, QuikStor and DoorSwap never focused on. They were merely targeted at the location management and keeping records sorted out. But they were not client-oriented too much. So, the first purpose of SpiderDoor was to provide an ability for tenants to rent a new unit, pay for the rent monthly and be notified about the balance and charges applied. With SpiderDoor, the tenants could download the iOS or Android app and do things they had been usually doing by calling location managers or visiting them personally.

  • SpiderDoor app - rental info
  • SpiderDoor app - charges
  • SpiderDoor app - available units
  • SpiderDoor app - choose location

Text Collector

Over time, SpiderDoor grew up and became a project useful for location managers as well as tenants. The managers wanted to see tenants and their balance on some kind of a dashboard. This was possible only by digging very deep into the third-party APIs in search of a possibility to get all active tenants with their phones and ledgers. After the phones, ledgers and unit balances were in place, Aaron came up with a new feature called Text Collector.

The Text Collector was supposed to serve as a payment reminder allowing users to pay for delinquent units right after receiving the reminder. A user would get a text notification, click on a unique payment URL, see the charges applied to the unit, fill out credit card details and pay the dues.

In their turn, the managers could set up the reminders to be sent on a certain day after the unit became delinquent and see the payments going through the Text Collector on their dashboards. The approach worked both for monthly and anniversary billing. This way, managers did not have to call tenants who forgot to pay on time and did not have to process their credit cards manually. The Text Collector was designed to be tactful and transparent so that the tenants could be aware about what they pay for and when.

Some location management got so interested in the Text Collector that they set up SpiderDoor accounts just for this feature alone.

Access control system

The next feature that became SpiderDoor's hit was integration with keypads. Keypads are installed in location gates to serve a few purposes. Their first purpose is to allow a defined set of people to enter the location or certain buildings inside the location. Second, keypads are to show activity logs so that location managers can see who is entering/leaving the buildings and when. There are many keypads in the market and all of them can serve the purpose but not all of them are easy to use. Most of them are quite hard to install. It is also difficult to keep them up-to-date and monitor the logs as their software is usually desktop-based and not supported well.

Viventor P2P lending platform

Just like the standard keypads in the industry have done, Aaron wanted the keypads to put delinquent users on hold - prevent them from entering the location - automatically. That task required much effort especially because it implied changing gate codes state as fast as possible. The ideal scenario was: a user gets to the location, tries to enter but sees the code being put on hold, opens the app, pays for the unit either in the profile or using reminders from the Text Collector and gets the code reactivated immediately.

That kind of responsiveness required SpiderDoor to pull user balance as often as every 15 minutes or less, which at first was not possible. But some API providers were so interested in this feature that they created a few API calls specially for SpiderDoor. These calls gave us enough freedom to create an access control system that supported keypad zones (when a user can access only a certain set of doors) and time zones.

This is how the SpiderDoor project with its access control system was released. Also, the project was featured on the SiteLink website for a second time.

Market expansion

Thanks to marketing skills possessed by Aaron Harwell, SpiderDoor got a significant number of users and gained success in the market. After two years it has:

  • around 500+ active self-storage locations using SpiderDoors iOS and Android apps in the United States and Canada;
  • 140,000+ units;
  • 123,000+ of which are occupied by tenants;
  • 7,000+ of which are active users;
  • over 140 keypads, as of June 2018, that are constantly synchronized with the management software.

This presence in the market attracts mass media attention to SpiderDoor, which results in magazine articles like this one.

Technical characteristics and challenges

SpiderDoor is hosted on a Linux-based server in Amazon EC2. The back-end is developed in Ruby on Rails. Since SpiderDoor performs a fair amount of synchronization procedures, most of its logic is performed by a background processor SideKiq which keeps jobs in batches and runs them according to a tricky schedule. This way, the SpiderDoor core works as a data hub that pulls data from self-storage management services, processes it and pushes it to keypads and other third parties.

Third-party services integrated in SpiderDoor are:

  • SiteLink API, SiteLink Reporting API, QuikStor API and DoorSwap API integrated through SOAP and used as the source of the location data. Also these services are behind such features as eSign, documents management and payment processing;
  • Twilio API for the Text Collector and arbitrary text notification;
  • OneSignal API for push notification;
  • Geocoder that allows for location filtering and search.

  • SpiderDoor web - managers
  • SpiderDoor web - permissions for managers
  • SpiderDoor web - latches

The web front-end of SpiderDoor is mostly designed for various managers that can control separate locations and groups of locations. They can adjust SpiderDoor settings, send notifications and monitor dashboards of all kinds.

End users (location tenants) can use Android and iOS apps to view their units and ledgers, submit incident reports, pay for their debts or pay in advance and open gates they have access to. In the near future, SpiderDoor is going to provide the ability to control individual proprietary “smart” latches.

In addition to the "selling" features described above, there were other technical challenges we successfully solved while working on SpiderDoor. The biggest challenge was, of course, the background synchronizer designed to pull a large amount of data from third-party management software every 15 minutes (and get even more data every night), convert it to the convenient structures and push it to keypads and other targets.

Another invaluable internal feature - not visible to the end users but very important anyway - was a flexible and transparent billing system for charging storage and location owners based on a custom set of SpiderDoor features they wanted to use.

The admin back-end (called SpiderAdmin) was a separate feature itself. It was designed to support various admin roles. This way, admins could manage separate locations and groups of locations, change settings for the mobile apps, send individual and group notifications to tenants and view their Text Collector stats on a dashboard.

Also, the mobile API was a big job itself. It was required to make it RESTful, cover with automated tests (the airborne gem - helped to make the tests look more like integration tests) and write API documentation using apipie-rails.

Customer feedback

Aaron Harwell is a very grateful kind of customer. Every developer who works for Aaron and is able to keep pace with him (as he is much more agile than most of software developers are) can count on an inspiring feedback. In his emails to Vadim Aaron wrote:

Aaron Harwell

"Just wanted to let you know once again how much I appreciate you. You have been a crucial part of getting this business up and running smoothly. I'd give anything if I had you here in our office working full time with me. I have so many other ideas and someone like you would set my mind at ease. Anyways, I just wanted to let you know how thankful I am for you".

Aaron also gave us 5-star review on Clutch.co.

This sort of feedback always gives excitement to put more and more energy in the project to make it successful.

Get in Touch