EAsy

Want to know what courses are the best fit for you? Just use EAsy.

Comment

Inspiration

We have all used Rate My Professors, but an overall professor rating does not answer the questions we actually ask when building a schedule.

Is attendance required? Are the exams online or open book? Is there a lot of homework? Does the professor give extra credit? Two students can look at the same class and want completely different things from it.

After talking with other students, we realized that many of them cared as much about the structure of a course as the person teaching it. The useful information was already hiding in student reviews. The problem was finding it.

That became EAsy: a course-first professor comparison tool that helps students find the class structure that fits them.

What it does

A student starts by searching for a course, not a professor. EAsy finds professors associated with that course and ranks each professor-course combination using reported grades, difficulty, and specific details extracted from student reviews.

Those details become useful tags such as:

  • Attendance Optional
  • Open-Book Exams
  • Online Exams
  • Extra Credit Offered
  • Flexible Deadlines
  • Study Materials Provided
  • Quiz Retakes
  • No Cumulative Final

Students can sign in with Google and choose which class features they prefer. EAsy then personalizes the rankings and shows which preferences have supporting evidence. If the reviews never mention something, we leave it unknown instead of assuming the class does not offer it.

Opening a result shows an AI overview of the available evidence: what students commonly report, what may make the class easier, what may take more effort, and how someone could prepare. Students can also contribute their own reviews, which are included in future scores and summaries.

The feature we are most excited about is syllabus-supported tags. A student who has reviewed a class can upload its syllabus, and EAsy checks whether that document supports the claims they selected. If it does, the tag receives a check mark. The file itself is discarded after processing.

EAsy does not promise anyone an easy A. It gives students a clearer picture of how a professor teaches a particular course so they can make a decision that fits them.

How we built it

EAsy is a full-stack TypeScript application organized as an npm workspace.

The frontend uses Next.js and React. An Express API serves course comparisons, aggregate scores, tags, and AI overview results. PostgreSQL stores the course catalog, professor-course pairings, reviews, student accounts, preferences, and cached summaries.

Our base score combines:

  • 50% reported A or A− outcomes
  • 35% inverted difficulty
  • 15% class-structure evidence

A student’s selected preferences can then add a limited personalized boost when enough reviews support them. This keeps the original score visible in the calculation instead of replacing it with an unexplained AI recommendation.

We used Groq for two focused jobs. It produces structured review overviews and checks uploaded syllabus text against a fixed set of student claims. We validate its output before saving or displaying anything. The model cannot create new tags, invent evidence, or treat the uploaded document as instructions.

We began locally with Docker Compose and PostgreSQL. For deployment, we used Vercel for the Next.js application, Render for the Express API, and Neon for PostgreSQL. Better Auth and Google OAuth handle student accounts. We connected everything to 3asy.tech using a domain benefit provided through MLH.

Challenges we ran into

Course normalization became a much bigger problem than we expected.

Students do not always enter official course codes in reviews. We found missing spaces, subject abbreviations, typos, course names, and labels such as CALC1, which refers to MATH 0220 at Pitt. A loose matching system could produce more results, but it could also quietly attach reviews to the wrong course.

We built a conservative normalization policy instead. It checks known aliases, validates subject codes, standardizes formatting, and only uses contextual matches when there is one unambiguous option for the same professor. Anything uncertain stays unresolved. We would rather show less data than confidently show the wrong data.

Tag extraction had a similar problem. Finding the words “attendance” and “required” is not enough when “attendance is required” and “attendance is not required” mean the exact opposite. We created targeted patterns and negation checks for the class details students actually care about.

The hardest feature was syllabus verification. Our first version relied on direct phrase matching. It failed over and over because syllabuses rarely use the same wording as our tags. A policy might clearly allow multiple attempts without ever saying “unlimited quiz retakes.”

We replaced that approach with a constrained Groq request. The model receives the syllabus text and an exact list of claims to evaluate. It must return structured results with supporting passages, and our server confirms that every quoted passage exists in the document. That gave us flexibility without allowing the model to make unsupported claims.

Then came deployment. Getting Vercel, Render, Neon, Google OAuth, Groq, CORS, environment variables, and a custom domain to cooperate was its own challenge, especially with the clock running.

Accomplishments that we're proud of

This was our first hackathon. In 24 hours, we went from an idea to a deployed application with course search, personalized rankings, Google accounts, student reviews, AI summaries, course normalization, and syllabus-supported tags.

We are especially proud that the product works as one connected experience. A student can create an account, choose their preferences, search for a course, compare professors, understand the reasoning behind a result, contribute a review, and support their claims with a syllabus.

We also built guardrails around the parts that could easily become misleading. EAsy shows insufficient-data states, treats missing evidence as unknown, keeps uncertain course labels unresolved, and does not present its score as a guaranteed grade.

Not bad for our first hackathon.

What we learned

We learned that building a full-stack product is mostly about the connections between its parts. Writing an individual component was rarely the hardest part. The difficult work was agreeing on data structures, keeping the frontend and API consistent, protecting private information, handling failures, managing Git as a team, and making local development behave like production.

We also learned when to abandon an approach. We spent hours trying to improve direct syllabus phrase matching before admitting that the idea itself was the problem. Once we changed the design, the feature finally worked.

Most of all, we learned that shipping something people can actually use feels completely different from finishing a class assignment.

What's next for EAsy

The next step is expanding beyond Pitt. The scoring and course-normalization systems can support additional schools and catalogs without changing the main idea.

We would also like to connect EAsy with official university scheduling data. That would separate historical student experiences from the professor-course sections actually available in an upcoming term.

Our biggest planned feature is a schedule builder. A student could enter the courses they need, and EAsy could compare the available sections against their saved preferences to suggest a schedule that fits how they learn.

The goal is not to find the easiest possible schedule. It is to help students know what they are signing up for.

Built With

Share this project:

Updates

Submission history