Engineering At Samsara

Documents: A Case Study in Scaling a Product at Samsara

July 16, 2019


Get the latest from Samsara

Subscribe now

At Samsara, we provide a product called Documents that gives fleet managers and drivers a customizable, paperless workflow to manage documents like Proof of Delivery records and fuel receipts. The Documents product recently celebrated its first birthday — supporting over half a million document submissions in the past year! In this post, we recap our journey of scaling Documents from an MVP feature to an enterprise product that thousands of our customers use every day as part of their connected operations.

Shipping fast

At Samsara, we obsess over our customers. We love shipping fast and getting feedback. Our Product team learned early on that many of our fleet customers craved more than just our route planning and monitoring products — they also wanted a system to manage paperwork during deliveries.

Our fleet customer base is super diverse — school districts, transportation companies, food & beverage services, and more! Therefore, we wanted to build a simple, yet customizable document management system where fleet managers could configure different types of documents (i.e. Proof of Delivery, Fuel Receipt, Citation, etc.) for their drivers to fill out, and drivers could fill out documents via the Samsara Driver mobile app during their routes.

Collaborating with the Product team on an MVP that we could ship fast, we decided on a simple document management system that only supported a single document type called “Proof of Delivery”. This is a document type with a single field to allow a photo upload for Proof of Delivery records.

Proof of Delivery flow

Proof of Delivery flow for drivers using Samsara Driver mobile app

Proof of Delivery document from the fleet manager’s perspective

Proof of Delivery document from the fleet manager’s perspective via our Samsara Dashboard. We had a lot of fun testing out this feature as we were building it! :)

With another engineer, Kelsey, we worked together to design a system that could allow us to move fast yet enable us to extend the system to support different document types beyond the Proof of Delivery document type we were starting off with. Therefore, we prioritized two things:

  • Microservice Architecture — By making the documents system a microservice, we could isolate our system from the rest of Samsara’s system and iterate faster as we gained customer feedback.

  • Flexible Data Representation — By future-proofing the data representation for what a document type is, we could easily expand on the Proof of Delivery document type to allow fleet managers to make other types of documents that have number, text, multiple choice, e-signature, barcode fields and more!

Documents System Architecture

Documents System Architecture

Specifically, we decided to store the fields of a document in an unstructured way as a BLOB column in our Amazon Aurora database. We also chose to use Protocol Buffers to serialize/deserialize and transfer the fields of a document between different parts of the system. In combination, this allowed for flexibility to expand on the types of fields we could support in the future.

Iterating on customer feedback

After launching Proof of Delivery, our customers loved it and wanted us to expand the document system’s capability to capture data beyond photos. Working with Sean, our team’s Product Manager, we analyzed the incoming customer feedback and concluded that fleet managers also wanted to capture valid string and number data from their drivers. For example, a large number of fleet managers wanted a Fuel Receipt document type which asks drivers to type in the number of gallons and price per gallon of fuel they bought on their routes.

Example of the Fuel Receipt document type

Example of the Fuel Receipt document type

Luckily, capturing new field types was easy given how we initially decided to store document fields. We did not need to make sweeping API changes between different parts of our system to support these new types of fields.

With a few extra lines of code, we not only expanded our functionality to support string and number fields, but also allowed for validation on types of fields. For example, a fleet manager could configure a number field to have a maximum of 2 decimal places so that drivers entered only valid fuel prices for their Fuel Receipt documents.

At this point, we added another engineer to our team, Utkarsh, and launched the newly expanded Documents product at Samsara’s quarterly Sales Kick Off. It was super rewarding to see the product that my team had worked so hard on for the last couple months get a huge round of applause from the entire company… Even confetti cannons were fired for this exciting launch!

Party emoji

Scaling to a larger, more diverse customer base

Once the expanded Documents product was launched, it quickly became a widely used feature. Thousands of customers used it for a variety of purposes ranging from tracking delivery of fresh produce to ensuring the safe drop-off of students at bus stops.

With a larger and more diverse customer base, we saw that different customers had different needs. For example, some customers wanted even more validation on fields, so my teammate Eric built a new multiple choice field type that would allow fleet managers to configure the set of values drivers could select.

Building a Fuel Receipt document type

Building a Fuel Receipt document type with a multiple choice field

We also noticed that some customers had unique workflows in how they manage documents. Some smaller-sized fleets loved using our web and mobile apps to read and write documents, while larger enterprise fleets preferred to interact with CSVs or APIs. In response, my manager Wei and my teammate Tommy built new ways for customers to streamline their operations: sending email/SMS alerts upon document submissions, CSV downloads for documents, and open APIs to read and write documents.

Exporting document submissions to a CSV file

Exporting document submissions to a CSV file

Seeing our customer base grow and diversify was exciting because they were using the Documents product in so many unique ways. These were all great signs that the product was successful and being adopted in many different markets!

One year later, Documents has become a major part of Samsara’s product, even supporting one of the largest grocery supermarkets in the US. With Documents, our customers have made their document management workflow real-time, saving thousands of dollars on wasted or lost paperwork.

Reflecting on the past year, I have learned a lot while building this product. I learned to be scrappy and hit the ground running, iterating fast on hard evidence drawn from customer feedback. I learned to have a vision of what the future of the product should look like in order to make the right system design decisions up front. As a full-stack engineer, I learned how to develop across our stack: building microservices, web/mobile apps, and API integrations. As a Team Lead, I learned how to quickly unblock my teammates and parallelize work so we can keep iterating fast as our team grew from 2 engineers to 8 engineers.

The Documents product is now going to be owned by our engineering team in Atlanta, and I’m excited to see this product scale in the many years to come!

Special thanks to everyone in the Workflow team for building the Documents product to be where it is today. And a big thank you to Kavya Joshi, Elisha Paul, Sean McGee, Wei Wu, Kelsey Lam, Sherry Wu, and Andrew Robbins for helping edit this post!

Swing by our page to check out our open engineering positions! At Samsara, we welcome all. All sizes, colors, cultures, sexes, beliefs, religions, ages, people.


Get the latest from Samsara

Subscribe now