← Back

How I Decided to Build Cornell Tech Hub

December 26, 2025

I didn't set out to build a platform. I just wanted an easier way to pick classes.

As a master's student at Cornell Tech, figuring out what courses to take was more frustrating than I expected. Basic questions—What is this class actually about? How heavy is the workload? What's the professor like?—were surprisingly hard to answer.

Most of the information technically existed, but it was scattered everywhere: old Google Sheets passed down through cohorts, half-remembered Slack messages, and word-of-mouth advice that depended on who you happened to know. RateMyProfessor was clunky and often unhelpful, especially for a school with rotating faculty and constantly changing course offerings.

After doing this dance for a couple of semesters, I kept thinking: this is a very solvable problem.

So I decided to build something for myself.

The Problem I Was Trying to Solve

Cornell Tech is small, fast-moving, and short-lived by design. Programs are one or two years, classes rotate frequently, and professors change. That structure makes it hard for institutional knowledge to accumulate.

In practice, that meant:

  • Course reviews lived in random spreadsheets that went out of date quickly
  • Academic planning required manually tracking requirements across documents
  • Useful discussions disappeared into Slack history
  • Good advice stayed locked in private conversations

None of this was catastrophic—but it was inefficient and repetitive. Every new cohort was reinventing the same system from scratch.

I wanted a single place where this information could live, even if imperfectly.

What I Built (and Why)

Cornell Tech Hub started as a side project. Part of it was practical—I wanted a degree progress planner I could actually use. Part of it was just wanting a fun, contained project to work on.

Over time, it converged around three simple ideas.

Course Information That Reflects Reality

Not a polished catalog, just structured, searchable notes from students who had actually taken the class. What the workload felt like. How the professor ran lectures. Whether the syllabus matched reality.

Nothing fancy—just information I wished I had earlier.

A Planner That Matches the Program

Cornell Tech programs have specific requirements, prerequisites, and sequencing quirks. I wanted something that could track progress without constantly cross-referencing PDFs and spreadsheets.

This ended up being the feature I personally used the most.

A Forum That Doesn't Disappear

Slack is great for real-time conversation, but terrible for long-term knowledge. I wanted discussions to be searchable, persistent, and organized by topic—so the same questions didn't have to be asked every semester.

Technical Choices (Lightly)

I kept the stack straightforward and familiar:

Next.js
TypeScript
PostgreSQL + Prisma
NextAuth (Cornell email auth)
Tailwind + Radix
Vercel

Nothing here was experimental. The goal wasn't novelty—it was reliability and speed of iteration.

Cornell email authentication was important so the content stayed community-specific. I also added basic role-based access control and moderation tools early, mostly to avoid problems later.

One unexpectedly time-consuming piece was scraping and normalizing course data from Cornell's catalog. The data exists, but not in a format that's easy to work with. Turning that into something structured and searchable took more effort than I initially expected.

What Didn't Work as Well as I Hoped

The biggest challenge wasn't technical—it was usage.

Because Cornell Tech programs are short and the student population rotates quickly, it's hard to reach a critical mass where the platform feels "alive" at all times. Some semesters, activity is solid. Other times, it's quiet.

That's partly structural and partly a cold-start problem I never fully solved. I didn't experience much pushback—just the reality that tools like this need sustained participation, and that's hard in a one-year environment.

I'm okay with that. The project still did what I needed it to do.

What I Learned

A few things became clear while building this:

  • Useful projects often come from very specific, personal pain points
  • You don't need broad validation to start—just a problem you actually have
  • Adoption matters, but it's not the only measure of success
  • The hardest part of community tools is not the code

Cornell Tech itself is fine. The professors are generally good. Whether the program helps you reach your goals—especially around AI and industry work—depends a lot on what classes you happen to take and how proactive you are. This project didn't change that, but it made navigating the system slightly less frustrating.

Why I'm Writing This Now

I recently revamped my personal site and had more time than usual. This project felt worth documenting—not because it "succeeded" in a big way, but because it represents how I like to build: start from irritation, build something small and concrete, and deal with problems as they appear.

Cornell Tech Hub is live at cornelltechhub.info. The project is also open source on GitHub under the MIT license—if you want to poke around the code, fork it, or build something similar for your own school, feel free.

If you're a current student and it helps even a little, that's enough. And if you're a developer sitting on a recurring annoyance and thinking, someone should fix this—sometimes that someone can just be you.