BroncoRMP

Inspiration

When students build their class schedules, they almost always end up doing the same thing: opening another tab for Rate My Professors, searching the professor, reading a few reviews, then going back to the schedule builder. We wanted to reduce that friction. That was the main idea behind BroncoRMP: bring professor insight directly into the schedule-building workflow. Since that information usually lives outside the registration interface, the process becomes slower and more fragmented. BroncoRMP was built to make that experience more seamless.

How we built it

We built BroncoRMP as a browser extension that surfaces Rate My Professors data alongside the schedule-building experience. The goal was to make useful information appear at the moment a student is choosing a course, instead of forcing them to gather it manually.

The project started with the professor data pipeline. I first wrote the web scraper in Python because it was the fastest way to prototype and a language I was more comfortable with it. Early on, I found that older scraping approaches were outdated, and that much of the site’s content was dynamically loaded. That made the initial version less reliable than expected. Once it became clear that the Python code would not plug directly into the extension the way we needed, I used AI assistance to help convert that logic into JavaScript, and then continued refining it from there so it could run in the extension environment.

The work became specialized across the team: I focused on the original scraper logic, the transition from Python to JavaScript, and getting the extension-side data flow into a usable form. Justin worked on getting the professor rating to display properly when the page opened, which was important for making the extension feel immediate and useful. Alton focused on fetching the review data specifically and summarizing it into a concise AI-generated review summary, so users could quickly understand overall student sentiment without reading every individual review.

What we learned

One of the biggest things we learned was that building something that looks simple to the user can involve a lot of complexity underneath. At first, the idea sounded straightforward: fetch professor information and show it in the extension. In practice, the actual data source was more difficult to work with because the site was dynamically rendered and older tutorials no longer matched the current structure.

We also learned a lot about the difference between building a standalone script and building for an extension environment. A Python scraper can be useful for testing and exploration, but a browser extension has very different constraints. That forced us to rethink how the data was fetched, how it was parsed, and how it was delivered to the interface.

Challenges we faced

The biggest challenge was the data source itself. Since the site content was dynamically loaded, the scraper methods we expected to use at first did not work reliably. That meant we had to spend time debugging how the information was actually being loaded and adapt our approach.

We also faced the challenge of deciding how much information to show to the user. Ratings alone are quick to read, but reviews contain more nuance. Showing all raw reviews would be overwhelming, so we needed a way to preserve useful detail while still making the extension feel lightweight and practical. That is what led to the review summarization feature.

Built With

• geminiapi
• javascript