HazTrack

Inspiration

Although AI has been seen as a tool of empowerment for many, the harsh reality is that it also creates a divide. An increasing gap between the people who have access to it and the people who don't. While it's true that AI can be amazing for those who can access it to catch up with others that also have access to it, that group of people inherently is a privileged one.

Thus, the inspiration for this project started with a question that was built on this premise: how could we use AI to improve the lives of those who generally can't access it?

There were a multitude of directions that we initially had. The words "developing countries" was definitely thrown around more than once. But ultimately, we decided to look within our community. To the people that we pass by each day when we go about our daily activities. The ones that interact the most with people who use AI despite not using it themselves.

Construction workers seemed like the obvious path at this point. They had incredibly communication heavy jobs that were generally not touched by AI. Any solution that had been proposed were often done quite poorly, another addition to a growing pile of random apps that were built without considering the actual user in mind and what they felt comfortable using.

What it does

HazTrack is our best attempt at integrating Slack within the already defined box of construction. Input wise, it turns a worker’s simple text in WhatsApp to a logged RFI (request for information) ticket in Procore, and adds it to a growing Slack database that can be easily searched using Slack’s native RTS feature. Output wise, it allows supervisors to send out mass safety hazard notifications straight into WhatsApp, and assigns RFI’s to the right people. The basic goal is to have everyone involved in the construction process continue using what they already have been using, while the supervisor can keep track of every input and output across the board in Slack.

How we built it

Like many, Claude Code was a great companion in our coding endeavours. It helped with the specific implementations of many pipelines, and executed them with great precision and detail. However, the exact workflow was planned out from us throughout the entire process. What steps exactly were included were all dictated by what we thought was best, each step deliberately calibrated to consider what worked well for the users we spent a lot of time researching and understanding, and what was easiest to maintain long term. Consistent questioning and challenges to Claude’s implementation was a common occurrence, so although most of the syntax was dependent on Claude, how that syntax weaved into the broader system was mainly done by us.

Challenges we ran into

One of the biggest challenges was definitely coming up with the idea in the first place. Like many, our first instincts was to continue pushing into well trodden territory, in hopes of finding some untouched and unfounded idea in a sea of already very well established AI routes. I would go as far as saying that almost half of the entire time spent on this project was used to research. In terms of implementation, one challenge came from trying to add the pictures into the Slack card. The reason for this was because the source photos were not publicly fetch able and slack_file blocks rejected the re-uploaded files. The fix came eventually when we decided literally look outside the box, and try attaching the photo in a threaded reply instead of within the card.

Accomplishments that we're proud of

Honestly, any end to end test that worked was a small accomplishment in it of itself. This was definitely very new territory for the both of us, and there were so many points during the entire development process where we didn’t even know where to start. Being able to iterate through the entire process and see the steps laid out from consistently challenging Claude Code, it allowed us to learn a lot more new things that we didn’t know before. There would be many firsts for this project. It would be the first time we made an AI wrapper. First time connecting SMS messaging into a pipeline. First time using Procore. First time using GitHub at a scale like this. So definitely, the fact that we were able to expose ourselves to so many of these things in such a constrained amount of time felt very rewarding.

What we learned

As mentioned above, I would say that covers a good chunk of it. One other unexpected thing was seeing how responsive API support was for apps like Procore. One distinct problem we had was trying to deploy our app on their side. For some reason it just couldn’t connect. Although it sometimes feels like these IT departments might be quite slow with these responses, it was enlightening to see how a simple email could go a long way. Personally for me, this would also encourage me to reach out to the n8n help centre when I accidentally made a node that falsely executed every second, using up all my executions for the month. Having seen the speed of response from Procore’s team, I was more willing to send an email to n8n’s team, and would end up getting my executions reset for the month. It was definitely very eye opening to see what I could accomplish simply by communicating.

What's next for HazTrack

Because our inspiration was always incredibly clear from the get go, no matter the outcome for this hackathon, my hope is that we are able to develop something that construction workers can genuinely benefit from. Doing research about the amount of workplace injuries that happen and how seemingly avoidable they could have been in hindsight, it motivates me to try to continue pushing for integration into this Slack app. Given that Procore was also a pretty big part of our build, I would imagine we could propose this idea to Procore as well, and see if they would be open to further development. But all in all, there is definitely a lot to look forward about for HazTrack.

Built With

• bolt.js
• express.js
• gemini
• javascript
• mcp
• node.js
• procore
• render
• slack
• twilio
• whatsapp