Every successful tech startup has to deal with scaling issues. These can include: building a reliable backend, tweaking the product/messaging for greater mass appeal, and hiring the people necessary to accomplish these goals. Houzz has been lucky enough to do pretty well on these challenges, but early success in hiring ended up creating a new challenge – providing adequate facilities for all the employees. Through clever rearrangement of our open seating plan, we were able to accommodate a lot of people in the office until we move into our new building later this year. The restroom, however, was not amenable to the same solution.
The men’s room in our engineering headquarters on University Ave. in Downtown Palo Alto started to hit its limits. Having a fraction of the stalls as in the women’s restroom, the capacity in the men’s room was usually sufficient, but was simply not enough for peak traffic. Lines would form, and less dedicated bathroom goers would simply return to their desks. These people would usually check back occasionally until the line had subsided, but I often worry that some people never made it. Certain e-mails about working from home for the rest of the day still haunt me.
Long men’s room lines became a daily occurrence, but many in the office saw them as portents of something even worse. A few disturbing issues could cause our bathroom infrastructure to collapse. First, there was a small club that prepared and ate muesli together for lunch. The dangers of too many people simultaneously eating a high-fiber lunch at work were all too apparent, and this group was a very evangelistic cult. Another concern was the free meals Houzz provided employees. With everyone eating the same food, we were always one undercooked meal away from total societal collapse. If we wanted employees to feel secure about the future of the company, something would have to be done.
Planning A committee was organized to find a solution that would offer temporary relief to this issue until the addition of a second stall. Most of the early suggestions from the committee revolved around usage prioritization. We didn’t have any problems before all of the newer employees joined, so there should probably be a system where older employees are able to either jump the line or eject a newer employee from the stall as needed. These were eventually rejected, as we felt that they might hurt recruiting. Some people felt that they may even cause legal issues.
We then moved on to more technological solutions. Perhaps we could build a reservation system that would allow people to queue for the bathroom from their desks. When nature calls, simply enter your request into the system and wait for a notification that your turn had arrived. We became even more excited by this prospect upon the realization that this system could even be used to auction off peak hour bathroom slots, smoothing demand while creating a new revenue stream for the company. We immediately moved to a conference room with a bigger whiteboard.
Within a few hours, we had a pretty solid design for most of the system. However, we were stuck on how to determine when someone was done using the toilet. A webcam wouldn’t work because there wasn’t an outlet in the stall. Self-report would be unreliable and require the exclusion of visitors who aren’t part of the system. Assigning fixed blocks of bathroom time would be wasteful. After banging our heads on the wall for a while trying to figure out a solution, inspiration hit. Like most problems in life, the correct solution to this would involve robots. We immediately tore the whiteboard containing our now useless system diagram off of the wall and chucked it in the trash.
The requirements for our robot were fairly simple. We would just need something that can detect whether the stall is available and post that information to Slack. We already knew how to post to it, so we were halfway done from the start. A door sensor is a pretty simple device, so pretty much anyone could make that too. Unfortunately, no one on the committee actually knew how to build a hardware device. After asking around the office, it turned out that no one who knew how to build a robot was both willing and able to spend their time on the Toilet Bot project. I still can’t explain that phenomenon.
The Hero’s Journey As someone who had both the time and the desire to build a Toilet Bot, I decided to learn how to actually do so. I enrolled in an embedded systems course online and got started. Within a week or two, I had built my first system that responded to a button press. Eureka! All I had to do was make the bathroom door press a button and I was done. I immediately ordered a Raspberry Pi starter kit. A few days later, I had built a Raspberry Pi system that would post an update whenever an attached button was pressed or released. After a little research online reading blog posts by other startups that had built similar projects, I replaced the button with a magnetic door sensor switch and was good to go.
I brought Toilet Bot 0.1 into the office and got some co-workers to help me install it on the stall. That’s when we realized that the Raspberry Pi has the same fatal flaw as the webcam: it needs to be plugged in! A little searching online revealed that there was no reasonable way to power it with batteries, so we were back to square one. After a little more research, I learned that while a Raspberry Pi was a good small computer, it wasn’t really meant for this type of work. Arduino is what people use for smaller embedded projects like this.
Looking into Arduino, it seemed like it would be easy to do the button detection but not to post an update. After failing to find reasonable and cheap WiFi capabilities for Arduino, I settled on some cheap radio transceivers. Within a few weeks I had built a working system at home in which the Arduino would send a radio message to the Raspberry Pi upon detecting a change in the door switch. The Raspberry Pi would then make the post. Toilet Bot 0.2 was ready. I had even purchased a 9V battery adapter to power the Arduino, as Arduino is a proper embedded system platform.
Before bringing the new bot into the office, I did a quick search online to see approximately how long I could expect the system to run on a single 9V battery. I found some varying information, but none of it claimed more than 2 days of life. To really get good battery life out of Arduino, you need to combine the components yourself on a breadboard, leaving out extraneous parts like the voltage regulator. This project suddenly became way more awesome. Another week or two later, and I had a small collection of capacitors, resistors, wires, and a chip on a breadboard. Surprisingly, it actually worked when I attached 2 AA batteries. Using much less power than the original device and spending most of its time in sleep mode, I estimated that the batteries could last for a year before needing replacement on this device.
Now that Toilet Bot 0.3 was ready, I brought it into the office to be installed with the help of a co-worker. The new stall could be built any time now. We had to hurry if we wanted to get this installed before it was rendered obsolete. After a week of fiddling with the Raspberry Pi to connect it to the office network and make the bot script run on startup, we installed the Arduino breadboard on the stall and created the channel. Everyone was very excited as I documented Toilet Bot’s maiden voyage. It actually worked! We attached a short explanation of Toilet Bot to the stall so that people wouldn’t freak out about seeing strange electronics in the bathroom. We were finally able to move on with our lives.
Victory and Obsolescence The next week or so was full of adulation. Many of my male co-workers kept coming by to thank me for my heroic installation of Toilet Bot. Some were just blown away by the strength of character it took to install such an ugly device in a prominent place in a design company. We even achieved internet fame when a visitor tweeted a picture of the bot.
The results were clear: people no longer waited in line for bathroom stalls. All waiting was now done at our desks until the bot would announce the start of a race to see who could get to the stall first. Unfortunately for the spectators, these races were far more rare than predicted. People would almost always arrive to find an open stall as promised.
Those heady days of Toilet Bot supremacy were never meant to last. I had barely finished installing a database on the Raspberry Pi to track bathroom usage when the contractors arrived to install the long-awaited second stall. Rather than the expected joy of the multiplication of our facilities, I felt a loss at the arrival of this new stall. How could my precious Toilet Bot be so easily replaced?
Not to be deterred, I built a second bot. Noticing that most of the parts were cheaper if bought in larger quantities, I did so and was able to build the second bot at a marginal cost of around $15. Having bought the parts in bulk, I offered to install bots in the women’s restroom. Having more stalls than the men’s, their restroom seemed like a great opportunity. I went around extolling the virtues of Toilet Bot to all the women in the office. One after another, they all expressed interest in the project until I brought up the possibility of installing it in their restrooms. One or two refusals could be a fluke, but after a few dozen it became clear that the women of the office are simply not interested. It defies explanation, but c’est la vie.
Fast-forwarding to today, Toilet Bot 0.4 lives on, with improvements such as LED indicator lights in the hallway outside the bathroom, allowing passersby who aren’t currently on Slack to stay connected with the latest toilet updates. The men’s room has become a utopian paradise, with the exception of the occasional 30-second line for the urinal. If only there were some way to over-engineer a solution to that problem…
For more information on the technical details of Toilet Bot, visit its GitHub page. Want to work in the kind of environment that encourages you to build a Toilet Bot and then brag about it? Join our team!