How New Relic helps Closegap move from DevOps to new builds

At Closegap, we provide thousands of schools across the United States with a free tool to support the mental health of their students. As a nonprofit, being budget-conscious and maximizing the value of our tech stack allows us to provide essential services to students when they need them most. As the sole developer at Closegap, supported by freelance dev teams and outsourced app developers, I ensure that our services are performant and accessible—young people won’t use an unreliable website. This can be a challenge at times, as our infrastructure is prone to seasonal and surge usage. New Relic becomes a crucial observability tool for user experience in that fluctuating usage environment—monitoring logins and ensuring the user login flow is maintained.

Taking a DevOps approach to manage cloud costs

I start each day by looking at our website's core vitals in New Relic. We deploy new features regularly, so checking recent deployments is an important morning activity. Monitoring our dashboards allows us to quickly identify and resolve any issues.

For example, our throughputs dashboard alerted us that an API call was being made on every page. We used the New Relic transactions pages to see the API call URL, checked this against our code base, and discovered that we had technical debt buried in our code. An old customization that had been removed was still left with API calls pulling unused data. New Relic enabled us to find the root cause. This technical debt also impacted our Heroku auto-scaling: additional servers were spun up at the start of every hour of the school day to respond to user queues. At that time, this was the most common transaction in our web app. By removing this, we reduced compute costs on our server, saving 15%-20%. We saved $1 for every $5-6 we were spending.

The emergence of Refactor Ops

Our website is built on Ruby on Rails with a React frontend. I’m really interested in the Hotwire approach—building front-end experiences in Rails—to simplify development and support building a mobile app with a smaller team. I want to build this new framework in the most efficient way possible. Initially, I considered waiting until we built a new frontend to transition from React to Hotwire; however, I decided to implement the Hotwire approach one service at a time instead. As with any new app development, you make trade-offs when you choose your architecture stack. We aimed to enhance the developer experience without incurring significantly higher server costs.

I started with the educator dashboards: schools want to be able to see if student mental health is improving overall. They focus on specific actions, such as ensuring students reporting hunger are enrolled in breakfast and lunch programs and that these hunger reports are decreasing. Using Hotwire, we can build these views in a much quicker development cycle. We need a fraction of the amount of code, and it’s easier to test features. A potential trade-off is the page load time. New Relic helps us measure and ensure that as we adopt this new software development approach, we maintain performance and usability without increasing costs.

Building an open-source community with Hotwire

We're also planning to open-source the application so that anyone can contribute. We know there are a lot of developers who share our values and want to contribute to our mission, as well as get some real experience with Hotwire. Having volunteers collaborate with us in sprints and pair with us to deploy new small projects is enjoyable for our team and rewarding for the participating developers. 

I frequently see questions on platforms like Reddit about the Hotwire approach: ‘Is it working? What does it look like?’ At Closegap, we’d love to serve as an example by sharing how Hotwire can be implemented. We now have the capacity to build this kind of developer community. With our app, a clear change agenda, and observability tools in place, we’re equipped to take action and monitor impacts effectively.