Atlas
Atlas turns a dense, PDF-bound degree catalogue into an interactive planner. Students drag courses across semesters and immediately see whether prerequisites, credit loads, and requirement groups still hold — replacing a spreadsheet ritual most people dread.
- Role
- Product lead & frontend engineer (team of 3)
- Year
- 2024
- Status
- Live
- Category
- Product
- Tools & technologies
- Next.jsTypeScriptPostgreSQLPrismaTailwindFigma
- Links
- Case study
The problem
Every semester, students rebuild the same fragile spreadsheet to check they can actually graduate on time. Prerequisites are buried in a PDF, and one wrong assumption cascades across two years of planning.
Context
A semester project for a software-engineering course, scoped as a real product rather than a demo. We had eight weeks, three people, and access to the actual degree catalogue as our data source.
Process
Modelling the curriculum
The unglamorous core was a clean data model: courses, credit values, requirement groups, and a prerequisite graph. Once that graph was correct, most of the product's value fell out of it almost for free.
I owned the frontend and the interaction model; a teammate owned the parser that lifted structured data out of the catalogue; the third handled the API and persistence.
Making constraints legible
The insight was to make rules visible while planning, not after. Drag a course into a semester where its prerequisite is unmet and it dims with a plain-language reason. Validation became a live, ambient thing instead of a submit-time verdict.
Research
- 01Collected 14 real student spreadsheets to understand the mental models people had already invented.
- 02Ran two rounds of hallway testing; the drag interaction needed clearer 'why is this blocked' feedback after round one.
Key decisions
Graph-driven validation
Prerequisites are a directed graph, so validation is a graph traversal, not a pile of if-statements. New rules became data, not code.
Optimistic, reversible edits
Every drag is instant and undoable. Planning is exploratory, so the UI had to make experimentation cheap.
Implementation
Frontend & data
The board is a React drag-and-drop surface with a normalised client store; validation runs locally against the prerequisite graph so feedback is immediate. Plans persist to Postgres via Prisma, and shareable read-only links let advisors review a plan without an account.
Gallery
Outcomes
- Adopted informally by ~40 students in its first semester.
- Cut a typical planning session from an evening to under fifteen minutes in user tests.
- Top-graded project; the parser approach was reused by a later cohort.
Lessons learned
- A correct data model is worth more than any amount of interface polish layered on a wrong one.
- Shipping to real classmates surfaced edge cases no rubric ever would have.
- Working in a team of three taught me to make interfaces — between people's code — as clean as the ones on screen.
Related work
Ledger
An AI-assisted personal finance tool that turns raw bank exports into a clean, categorised ledger you can actually reason about.
Signal
A retrieval-augmented assistant that answers internal support questions from a company's own documentation, with citations.