Every student knows RateMyProfessors. But it only answers half the question. It rates the professor — not the course. A 5-star professor can still be teaching a brutal, low-average class, and an "easy" course can be miserable with the wrong instructor. When you're building a timetable, you're choosing a course-and-professor pairing, and RateMyProfessors can't show you that.

The result: instead of guessing, a student can answer the real question — "Which course, with which professor, gives me the best experience and outcome?"

Behind the scenes, a data pipeline runs on a schedule. Think of it as an assembly line: raw, messy review data goes in one end, and clean, ready-to-use files come out the other, which the website reads directly. There's no database server to maintain, the site is just fast static files that refresh themselves.

This "medallion" pattern (bronze → silver → gold) keeps a clean audit trail: every number on the site can be traced back through the layers to the original review it came from.

The first version worked, until it didn't. Because the site read files straight from storage, every professor page downloaded the entire 76 MB reviews file and sifted through it for one person. On a good connection it took 20–35 seconds and the download failed about half the time mid-transfer. Not good enough.

The fix was sharding: instead of a few giant files, the pipeline now writes one tiny file per course and per professor. A page grabs only the few kilobytes it actually shows, a ~99% cut in data per page. Same information, delivered surgically instead of by the truckload.