Routegy

We started reaching out to property management companies, building/facility managers, and similar companies. It quickly became apparent that we were not talking to the right customer. They had little insight into the individual people utilizing their spaces and often considered their existing tools adequate.

So we started talking to the companies leasing spaces, and immediately found a match. Office administrators, site managers, and similar roles knew the pain of managing people within their buildings, fielding requests, and trying to keep day-to-day business running smoothly.

We started shopping around a pilot program and found our first taker. We can't disclose the name just yet, but you would recognize the company's name. This will be a true first test of our product and assumptions. 🤞

We divided and conquered the build-out of the three major components of the Routegy system: the end-user mobile web app, the customer-facing administration app, and the backend API.

We chose Nuxt/Vue for the web apps (along with Buefy for the UI) and Django for the API due to our experience and fondness of Python.

The system sits on AWS and makes use of a number of services to cover boilerplate stuff like auth (Auth0). It's pretty over-engineered for a typical MVP (M might stand for "maximum" in our case), but we're engineers at heart and chose to harden certain things up front.

We mapped out what we thought a good experience for reporting issues and making requests would look like. We knew we wanted it to be as low friction as possible, so we immediately gravitated to a mobile-first web app without a sign-in requirement, and a focus on touchless interactions via QR codes, NFC tags, and IoT devices like buttons and sensors.

In addition, context is key, both from the perspective of offering a means for people to create issues and requests and including that context when the proper person is notified. Context is the where, what, and when, and often we can obtain context automatically. If someone is in the kitchen, we don't need to ask them where they are. We know when they interacted with the touchpoint, and often we know why they're interacting with it, or at least the general reason.

When talking to perspective customers, we learned that there are often multiple teams and systems involved depending on the type of issue or request. This led us to design a system that could integrate with any number of tools, as well as offer the ability to assign specific actions to specific touchpoint interactions.

Our basic design was complete, and it was time to start coding.

We (Hawker, Pawel, and I) kicked ideas around over the course of a couple years. Some were better than others, and some made it well past the conceptual phase. However, nothing really stuck or clicked.

Then we started talking about how annoying it was to encounter issues or need to make requests in the office. Usually, this involved going back to our desks, navigating the corporate ticketing system, and trying to figure out where to create the ticket. Things had to be pretty bad to make it worth the effort.

This got us talking about similar experiences out and about the city, at events, in stores, at restaurants, and so on. It seemed like there was a common problem with connecting people in spaces to those that can help them. We started talking to the people responsible for fielding issues and requests, and they voiced frustration as well. By the time something made it to them, it was often Very Bad and nobody was happy.

We decided to dig in.