Project

OurPurduePlan

React + Elixir tool for building and sharing branching degree plans with prerequisite checks and course difficulty stats.

Role: Frontend engineer
Duration: Spring 2024
Team: CS 307 team: Neil Van Eikema Hommes, Cooper Chiappetta, Jack Roscoe
Tools: React, TypeScript, Elixir, Phoenix, PostgreSQL

Problem & Context

Planning a degree at Purdue usually means juggling MyPurduePlan, spreadsheets, and Reddit threads. MyPurduePlan makes it hard to save multiple “what-if” plans or reuse work from other students, so people rebuild nearly identical four-year plans from scratch. OurPurduePlan set out to centralize that process: give students a single place to create multiple plans, branch off shared early semesters, and see what has worked for others.

The app targets both students and advisors. Students can experiment with majors/minors and share plans on a forum, while advisors can recommend edits or whole plans. A difficulty rating system for courses and simple statistics help people reason about workload when they are constructing or comparing plans.

What I did

Implemented the login / logout and account-creation flows on the React frontend, including client-side validation and token handling with the Phoenix API.
Built the drag-and-drop plan editor UI so students can add courses to semesters, move them between terms, and grow plans over more or fewer than four years.
Implemented prerequisite warning UI and course-difficulty interactions so users can see when a plan violates requirements or stacks too many hard classes together.
Helped design the overall client–server architecture (React + Phoenix + PostgreSQL) and data model for plans, branches, semesters, courses, and forum posts.
Co-authored the design document, backlog, sprint plans, and test plan, translating user stories into acceptance criteria and test cases.

Process

Architecture & tech stack

We built OurPurduePlan as a classic web client talking to an Elixir/Phoenix REST API backed by PostgreSQL. React gave us the kind of responsive UI we needed for drag-and-drop plan editing, while Phoenix and Ecto handled persistence, prerequisite checks, and statistics over plans and course difficulty ratings.

Authentication is done with Phoenix-signed tokens that are sent in an HTTP auth header. The frontend lives on its own DigitalOcean droplet, and the API + database share a separate droplet, keeping deployment and scaling concerns cleanly separated.

Team workflow

As a team we maintained a product backlog of user stories (e.g., branching plans, course difficulty ratings, forum interactions) and pulled them into three sprints. Each story had explicit acceptance criteria, so it was clear when a feature was “done.”

We backed this with a test plan that outlined unit tests and integration tests for critical flows like authentication, plan creation, branching, and posting to the forum, which kept regressions manageable as the project grew.

Outcomes & Impact

Delivered a fully working full-stack web app for CS 30700 that implemented branching degree plans, forum sharing, course-difficulty ratings, and prerequisite warnings, deployed on DigitalOcean.

Got hands-on practice with a React + Elixir/Phoenix + PostgreSQL stack, plus translating a fairly large set of user stories into a concrete data model, API design, and frontend UX.

Reflection & Next Steps

On the technical side, this project pushed me to learn to ship a polished React frontend. Having a detailed design document and backlog made that manageable, and it reinforced how much easier implementation is when requirements and ownership are clear up front.

If I revisited OurPurduePlan now, I would invest a bit more in automated end-to-end tests across the plan editor and forum.