Pixelatd: course reviews that say what a class actually asks of you
- Role: Mostly solo. Product idea, design, front end, database and deployment.
- When: Spring 2026 to now
- Stack: Next.js (Turbopack), TypeScript, Supabase (Auth, Postgres, RPC functions), nginx
- Live: pixelatd.itp.io
- Result: Shipped in time for registration season and used across the IMA and ITP student body.
The problem
Picking classes at NYU goes through Albert, the registration system. Albert tells you a course code, a time and a paragraph written by the department. It does not tell you what the class is like.
So students do what I did: ask friends, scroll group chats, and guess. It still goes wrong. I once took two electives just to learn TouchDesigner, and both barely covered it. People in group chats still recommend them with “I heard this class teaches TD.”
A star rating would not have saved me: both classes might have been rated well. What I needed was a description of the work a class demands, written by people who took it. That became the design brief for Pixelatd.
Designing the review
IMA and ITP classes pull in different directions. One is soldering and Arduino, the next is critical reading, the next is sound design. A single score flattens all of that.
So a Pixelatd review has no overall rating at all. The one required part is an Aspect Radar: six axes, each scored 0 to 5 by clicking dots on the chart.
| Axis | What it captures |
|---|---|
| Physical computing | Circuits, sensors, microcontrollers |
| Coding | How much you program |
| Design | Visual and interaction design |
| Narrative | Story, writing, concept |
| Fabrication | Building physical things |
| Sound | Audio and music |
Almost every class in these two programs is some mix of the six. A radar reads at a glance: a spiky shape toward coding and fabrication tells you more than “4.2 stars.” Each review shows its own small radar, and course listings show the combined shape.
Around the radar, the form asks a few optional, concrete questions:
- Course style: two sliders, Seminar to Production and Chill to Grind.
- Hours per week, in half-hour steps.
- Instructor and term, since the same course can be a different class with a different teacher.
- A short comment, capped at 350 characters. Short enough that people actually write it.
The form refuses to submit only when every axis is zero. Everything else is optional, because a half-finished review is worth more than an abandoned one.
Tags: letting students name things
The radar doesn’t cover “attendance is mandatory” or “you will teach yourself everything,” which is what people actually ask each other before registration.
Each review can carry tags. There is a starter set (Easy A, Self-Taught Heavy, Portfolio Builder, Mandatory Attendance, Reading Heavy, Group-work Heavy, Solo, PComp Heavy), and anyone can propose their own. Tags belong to the course, not just the review. When the next person reviews the same class, the form shows “Also used by others for this course” with a count next to each tag, so they can back an existing tag with one click instead of inventing a near-duplicate.
Getting people to write reviews
A review site with no reviews is just Albert with a nicer font. The hard part was giving people a reason to write.
Pixelatd runs a small points economy, all inside Postgres:
- Writing a review grants points through a database function, and so does receiving a Helpful vote. Keeping this in the database keeps the rules in one place.
- Every review can be voted Helpful or Not helpful. The most helpful ones get a Popular Reviews spot on the leaderboard page.
- The leaderboard has three views: All-Time, This Season (which resets every season), and By Field, which ranks reviewers by how many reviews they wrote that scored 3 or more on a given axis. That surfaces the person to ask about sound classes, not just the person who reviews the most.
Badges sit next to usernames on every review:
| Badge | Earned by |
|---|---|
| Pioneer | Being among the first 100 reviewers |
| First Reviewer | Being the first to review a course |
| Sentinel | Submitting 10+ reviews |
| Tag Master | Contributing 50+ tags |
| Lifesaver | Writing a review that got 20+ Helpful votes |
Anonymous posting is allowed, but it earns nothing. The form says so when you tick the box. Honest reviews sometimes need anonymity, so I didn’t want to ban it. I just made the named path more rewarding.
For moderation, admins can shadow-ban a review. It shows faded with a label in the admin view.
Building it
Courses and their sections (instructor, meeting times) live in Postgres, covering IMA (IMNY-UT) and ITP (ITPG-GT). Search filters by program, term and minimum number of reviews, and sorts by course code or most reviewed.
Averaging every review on every search would get slow, so course numbers live in a stats table that a database function refreshes whenever a review is created, edited or deleted. Search reads one row per course.
Students can also wishlist courses and mark ones they have taken.
I built it mostly alone between my own classes and work, and shipped it right before registration opened. The site has an Updates page for dev notes, and the first one says it plainly: still a work in progress, please send bugs.