Four months ago, Tristan Siegel was an aspiring archeologist and William Jeffries was an accountant. Fresh out of Flatiron School’s Web Development course, they’re already out to make something that matters. They started building Heat Seek NYC to help address the need for livable heating in NYC’s lowest-income apartments. Landlords can lower the heating far below room temperatures in their buildings to save money or drive out poorer tenants. Heat Seek NYC helps validate tenants’ claims against their landlords with the power of cold hard data—and gives tenants agency over their living environments.
After a very warm response to Heat Seek NYC at NY Tech Meetup, William and Tristan are leveraging their newly-found community to make their app bigger and better. They’ve learned a lot (everything from brand new technologies to socio-political landscapes of underserved areas) to make Heat Seek NYC what it is now. But they also recognize that, for their app to make a difference to whole communities, they’ve got plenty of work ahead of them.
Let’s start with what were you doing before you learned to program.
Tristan: Before Flatiron I was toying with the idea of going to graduate school to become a professor or maybe a teacher. The entire time I felt unsure of what I wanted to do. While talking with a friend who was a Computer Science major, she recommended I try Codeacademy. I did all their front-end courses and loved it. I then realized my own limitations in trying to implement what I had learned while trying to make my own website. I felt kind of defeated until I realized that I needed more guidance, and that I could go back to school to learn how to code instead.
William: When I was a CPA, I quickly realized there were a lot of inefficient manual processes that I thought should be automated, and in fact I found it was a lot more fun to figure out how to automate accounting than to actually do it. I started writing Excel macros in VBA and realized that I could add a lot more value doing that, which is what brought me to the Flatiron School.
So what made you start building Heat Seek NYC?
William: We wanted to be able to help people in some way with this new skill we were learning. I came across this really interesting technology called Twine which got funded on Kickstarter that I wanted to play with. They build wifi-enabled sensors for your home that are quick and easy to set up.
I ended up writing a blog post about maybe using it help measure temperature for people in lower income areas whose landlords won’t keep the heat on. At the time, I didn’t really know anyone who needed it. But my post seemed to resonate with Tristan.
Tristan: Yeah, my mom is actually a social worker in the South Bronx. She knows a lot of clients who experience problems with temperature in their apartments. To test the app out, we were actually able to arrange to have a Twine placed in one of her clients’ apartments for proof of concept. This was a great opportunity.
And I hear they’re in even more apartments now. Where?
Tristan: There are three installed now—one in the south Bronx and two in Crown Heights. We’re really lucky to be able to collect real world data.
William: And we’re researching hardware options to make things cheap enough to scale up. Initially, we built something that was good enough for a presentation at the school. We were having a lot of fun with it, so we just kept building.
In your presentation at NY Tech Meetup, you used the phrase algorithmic advocacy. What does that mean?
William: It means automating advocacy and using technology to stand up for people. Right now what lawyers do to support claims—and this is what everyone does—is ask their clients to take a piece of paper and a pencil and, when they remember, write down the temperature and the time of day. Then in court, the tenants testify that they took all that information down accurately and in good faith. And Judges don’t take it that seriously. There’s a lot of room for bias and error.
Tristan: In this case, technology can remove hearsay associated with temperature readings by having a third party control the readings and having taken automatically without human involvement to ensure the accuracy of the data they get and make sure it holds up in court.
Cool! But how do you know what kinds of data will hold up in court and best support tenants’ claims?
William: There must have been emails floating around back and forth in the legal advocacy world about this technology. We’d get emails periodically from lawyers at different agencies who were sort of interested in the technology and wanted to hear what we were doing.
The Urban Justice Center was the first organization we talked to who had a specific lawyer with a specific need and enough time to talk to us. They do non-profit legal work for people, especially in lower income areas. They have a lot of clients dealing with temperature problems and were already looking for a solution to make the process of gathering evidence more painless. They were really helpful. They advised on the user interface and what makes strong evidence in court.
Tristan: Our contacts at the Urban Justice Center were really helpful. They sent us a copy of the HPD (Housing Preservation and Development) log from the Department of Housing used by actual inspectors. We modeled the data on the PDFs we generate after that. So judges will be familiar with what they’ll be looking at. Knowing how people use the data also helped us model our site’s userflows to best fit a tenant’s experience.
Working with the Urban Justice Center was like a crash course in agile development and how to work with a client. If they said “this is isn’t what I meant, or this is what we need to show,” we had to make changes to fit what the actual needs are.
So how does Heat Seek NYC work?
Tristan: Heat sensors in the apartment collect temperature data. Heatseek scrapes the information from Twine’s site, including every hour the temperature was below the legal limit and displays all of the data in charts and graphs that tenants can print out.
William: We used a lot of technologies, but we used Twine as the heat sensor. Twine comes with an API, but the API will only send requests to your webserver if there’s a triggering event (like if the temperature goes above or below a certain threshold). So you’re limited to a fairly low number of these triggers. For our application, we needed to be able to just ping their server and find out the temperature. That information is available on their website if you’re a regular user. You can log in and just see that number, but the API doesn’t expose that. Our work around was basically to build our own scraper to scrape their site.
Did you experience any particularly challenging moments when building it?
Tristan: I can think one moment in particular. When we were scraping Twine’s website for the temperature information, it would ban us because we’d accessed their website through a headless browser (PhantomJS). We had to figure out how to mask that to make sure it seemed like it was always a real person checking it out. We did it by pretending we were an iPhone user who would log in three times every hour on the hour.
William: We were really green when we started building Heat Seek NYC. A lot of things that other people would find simple were difficult for us. For example, we had to teach ourselves to learn Devise—which is a great tool for user authentication—and then we made our own authorization system, as well. It was a good learning experience with a lot of big challenges.
You mentioned that you had to teach yourselves Devise. How many of the technologies you used did you learn by yourselves?
Tristan: Most of them.
William: Yeah, and Flatiron people helped us. We usually talked to a TA or an instructor beforehand, and said, “Here are some of the technologies that we think would be a good fit. What do you think, and how can we learn them?”
Then it was the foundation that we learned in Ruby, and all the experiences we had. For example, there was a deploy day were Spike Grobstein came in and taught us about deploying. He’s the one who taught us to use EGINXX and Passenger.
It seems like the Flatiron School’s approach to teaching technology is not to teach every tool you’d ever need but to give you a framework that helps you identify what tools to learn next, and to teach you how to go about doing that efficiently.
Are you planning to keep working on Heat Seek NYC?
William: Absolutely. We’re hoping this will be a long-term side project that we can work on in an open source model. We’re hoping to work part time, indefinitely to make a difference —and to get ready for NYC Big Apps. So far, we’ve created a core team of six people, including some non-technical people.
We want to scale it up to a point where we could actually make a difference in the city, we might need to migrate to a cheaper sensor technology—we’ll either manufacture sensors ourselves or find a lower cost option off the shelf. We’re currently working with a hardware specialist to figure out what the best product is, then the best way to scale it.
Cool, so you’re building out an advisory team for NYC Big Apps?
William: I would call them the core team. They’re partners and collaborators more so than advisors. We fleshed out our team with a designer, a hardware specialist, and a business development person, and a lawyer so we can put together a better product. We’ve already seen the benefits direction and efficiency in general.
Building out the team after we presented at NY Tech Meetup was getting overwhelming for the two of us. We were inundated with support from people who wanted to work with us, contribute hardware and connections, and help out with our technical challenges. It’s been great.
Keep an eye out for Heat Seek NYC in NYC Big Apps—a competition that brings NYC’s sharpest minds to solve it’s biggest challenges. We’re really excited to see where it goes.
Heat sensing with Twine
Developed in Ruby on Rails
Deployed to Digital Ocean
PostGreSQL on the backend
Served with Passenger
Data mapped with LeafletJS
Charts from Highcharts with gem wrapper Chartkick
Scraped by Poultergeist, PhantomJS, and Capybara