Project overview
This semester, while managing 40–50 hours of coursework each week, our team took the initiative to design and build a frontend drag-and-drop course planning web application. Tailored to help students visualize and align their learning paths—whether in full-stack development, software engineering, or machine learning—the tool empowers informed academic decisions.
From drafting user stories and prototyping in Figma, to building features using React (Create React App) and TypeScript, and deploying through Render, every step was a hands-on learning experience. We integrated Strapi as our backend and adopted GitHub Projects, MoSCoW prioritization, and bi-weekly sprints to simulate real-world product workflows.
💡 Key Highlights:
- Two distinct types of drag-and-drop interactions
- Full-cycle development using React + TypeScript + Strapi
- Agile planning with MoSCoW and team sprints
- Seamless cross-functional collaboration throughout
- 📌 Upcoming features: PDF report generation, a more polished UI — and more on the roadmap!
- 🙌 Built by a dedicated team of 4-6 NEU students, combining design, frontend, backend, and deployment — from zero to something meaningful.
Career Pathway Course Planning Application
💬 A Spark from a Conversation
The process began after a meaningful conversation with Director Ildar Akhmetov, where he encouraged students to build meaningful projects outside the classroom. A few of us stayed after the session, sharing our frustrations around course planning and alignment with real-world goals.
The challenge was turning vague ideas into something concrete—but with support from Professor Neda Changizi, we found the courage and structure to start.
What we learned is that successful projects often start with a group of committed, goal-driven individuals—and a small spark of motivation, supported by a strong safety net of encouragement.
🎯 The Problem We Saw
Many students—including ourselves—often feel overwhelmed by course selection.
- Which courses are even available?
- What are the rules?
- Am I on track for the career I want?
The process often felt fragmented. While the information was technically available, it wasn’t always easy to navigate or interpret. During advising sessions, we frequently found ourselves without a clear visual plan—something concrete that could support more focused and productive conversations.
That was the gap we wanted to fill.
👉 The image on the right was created by Weihang Ding and Jiuyue Shang.
From Problem to Product – Our First Sprint
After applying the MoSCoW prioritization method to identify key pain points, we moved on to defining the scope for Sprint 1. We drafted feature ideas on GitHub, sketched layout concepts in Figma, and coordinated asynchronously.
Establishing a clear structure early on helped reduce friction later. Even simple tools—like GitHub issues and visual views—made a big difference.
👈 Special thanks to Yifei Ma for breaking down tasks into GitHub issues and organizing the data structure throughout the process.
🧩 The First Merge – Real Code, Real Conflicts
Then came reality: merging code
We soon discovered that our components were too tightly coupled at first, which led to frequent merge conflicts and broken logic—issues that are difficult to avoid early on. Pull requests clashed. Everyone’s code was “right,” but resolving those conflicts took time.
So we met up in person to discuss and decide which one or both we should keep. For most of us, it was the first time we experience how to deal with the merge conflicts. That’s awesome!
🧠 Drag-and-Drop – Where Complexity Hides
Our most difficult technical task was implementing drag-and-drop. It sounded simple, but after hours of debugging, we realized the system needed three coordinated layers: drag source, drop target, and a shared provider using @dnd-kit/core. We also had to support two behaviors:
- Copy and drag (adding a new course from the master list)
- Move and drag (reordering or changing semesters)
These interactions had to be intuitive for users—but technically accurate in tracking course state, enforcing limits, and avoiding duplication. It taught us that clean UI often rests on deep architectural understanding.
🗂️ State Management – When useState Wasn’t Enough
Managing course data started with useState, but we quickly ran into its limitations. Dragging, deleting, persisting across sessions—it became too complex.
We moved to Zustand for centralized state, added localStorage for persistence, and rebuilt parts of our logic to track course instances with unique IDs. That helped us scale without sacrificing stability.
Planning for scalability, even in a student project, saved us from future chaos.
🤝 Team Rhythms – Building More Than an App
Looking back, what made this work wasn’t just the tech—it was the people. We self-assigned tasks based on interest, held each other accountable, and flexed around school, jobs, and life. There were disagreements, but always a shared sense of direction. We also helped each other learn—whether it was one-on-one Git guidance, layout tweaks in Figma, or debugging merge conflicts.
A good team doesn’t wait for permission. It moves, adapts, and finishes strong—together. ❤️
📝 Submit a Membership Application
If you’re excited and ready to join us, please fill out our Membership Application Form (it takes about 5 minutes), or click the button below to get started. We’ll follow up shortly to schedule a brief 1-on-1 or group chat to align expectations and answer any questions you may have.
✏️ You can edit your responses after submission.