GradePilot

Inspiration

Students usually aren’t failing because they never tried. They’re failing because time is finite and study hours get spent in the wrong places. When you’re juggling six classes, limited hours, and high stakes finals, the honest question isn’t just “what should I study?” It’s where the next hour actually buys you GPA.

We built GradePilot because a lot of “study apps” stop at generic lists or chatty assistants. We wanted something closer to a simple optimization mindset: respect exam weights, credit hours, and how many days you actually have left.

What it does

GradePilot helps students prioritize study time with a GPA minded planning approach, then makes the output easy to act on:

• GPA focused planner: You plug in classes, where you stand today, final weight, credits, difficulty, and exam timing. You get back a prioritized allocation that highlights where extra hours tend to matter most.
• Calendar style planning: You can skim the plan in a month style view, open a day to see what’s on deck, and export helpful schedule outputs.
• Student dashboard: One place for GPA tracking with charts, hour by hour day blocking, and a to do list that supports priorities, categories, due dates, search, and filters.
• Accounts + persistence (demo friendly): Sign up and log in with client side persistence so the hackathon demo still feels like a real workflow end to end.

How we built it

We shipped GradePilot as a Next.js 15 app using the App Router and React 19. Styling is Tailwind, motion is Framer Motion, and charts use Recharts for GPA trends. For the hackathon timeline we leaned on localStorage so sessions and module data persist without standing up a backend.

The planner core is built from explicit scheduling and priority logic, not vague “AI guesses,” which keeps results explainable and easier to reason about.

Challenges we ran into

We kept bouncing between moving fast and shipping UX that feels legit. Dashboards, responsive layouts, charts, and planner outputs all fight for attention, so we had to protect one clear loop the whole time: inputs, then priorities, then a calendar you can actually follow.

Persistence on the client also forced boring but important choices about shape of data, light migrations, and per user keys so todos, GPA data, and planner state don’t stomp on each other.

Planner screens were especially picky on mobile, so we reworked layouts more than once until dense info still felt readable.

Accomplishments that we're proud of

We’re glad we didn’t ship a fuzzy “study assistant” with no point of view. GradePilot has a stance: make tradeoffs visible under constraints.

We’re also proud the product feels cohesive: intentional motion, modules that fit together like one student workspace, and a demo path that feels complete (auth, planner, trackers, saved state).

What we learned

When you frame studying as tradeoffs, people engage more when the app shows why something is prioritized, not just what to do next.

We also learned scope creep is real. Add GPA charts and scheduling and suddenly everything wants to be “essential.” Strong defaults and ruthless cuts matter.

What's next for GradePilot

If we had more time, we’d pursue:

• A real backend with safer accounts and sync across devices
• GPA modeling that’s validated against more grading scales and transcript rules
• Deeper calendar integrations and exports that fit real campus rhythms
• Study groups, reminders, and optional privacy preserving insights from aggregated anonymized usage

Built With

• css
• next.js-15
• react-19
• tailwind
• typescript