Description

This API was hooked into a React Native front end with the admin panel in plain Rails. The startup's mission is simple: Users sign up to get their car filled with gas. The drivers come fill the cars with gas.

User signup was pretty standard to implement. It had to include information about their car's make, model and license plate number as well as general location. The fleet had three trucks to respond to service orders. The API needed to break all the stops for the day into three geographic sections, then decide how many trucks are needed in each. Also, it takes 10 minutes to perform a service stop, so the app was designed to have four two-hour blocks of time (with an empty hour in the middle for drivers to eat lunch). The hardest part was figuring out what to do with incoming orders while the drivers were out in the field.

Leaning heavily on the Open Source Routing Machine, driver routes were calculated on the fly. If there was time left in a timeslot, the stop was inserted into the route in real time. If there wasn't, the stop was moved to the next available time slot and the route was recalculated. Once a stop belonged to a timeslot, it was not moved, so finding time for a new stop never jeopardized the service stop of someone who was already expecting it in a specific range of time for that day.

The admin panel handled all route reporting (with a JavaScript-heavy historical record of serviced stops visualized in Google Maps) and invoicing through Stripe. There was a coupon system that handled both percentages and raw amounts. The math for all this was straightforward but grew in complexity as each stop was added to a timeslot.

The biggest challenge

Timing and state change. We didn't want to bump someone from one time slot to the next, but we also didn't want to have the drivers chasing new service stops for the last half of their shift. We also also didn't want to hammer the Open Source Routing Machine whose EULA forbids excessive use but does not put the terms more concretely than that.