Grademap

Overview

Grademap is a study companion app designed to show students exactly where they stand in their academic journey, and tells them what they need to do to hit their targets. It crunches the numbers for you, structures your data in a way that supports your studies, and gives you real actionable plans.

Why I built it

I got the idea when I was with my friends on my course, and we were stressing out trying to figure out what our overall grade was after a hard lab. It was super tough, especially after spending all our brainpower actually doing the work. So, I got the idea of making an app that does the math for you and breaks it down for you to show you exactly where you stand and what you need. From there, I wrapped that core up in helpful utilities and features, and now we have Grademap!

Keeping the numbers honest

The hard part of this was dealing with the fact that marks come in slowly across a semester, so most of the time your data is incomplete. If you just treat anything unmarked as a zero, the app will happily tell someone they are failing when the truth is they haven't sat anything yet, and that is a horrible thing to show a student who is already stressed about their degree.

So the engine has to keep three things separate that are really easy to lump together: work you did badly in, work that hasn't been marked yet, and work that doesn't exist at all. Then it weighs everything up against your classification boundaries before it says anything.

Keeping everyone's data separate

Grades are about as personal as student data gets, so this wasn't something I wanted to leave until later. Auth goes through Supabase, and every table sits behind row level security policies in Postgres. That means access is enforced by the database itself rather than trusted to the app, so even if I write a bug in the frontend it can't turn into someone reading another person's grades.

What runs on the server

Anything that needs a key, or needs to be the same for everyone, runs on the server. The AI chat and study features go through Supabase edge functions, and there are database triggers and functions handling the bits of work that make more sense sitting next to the data than in the app.

Shipping it

Releases go out through GitHub Actions. Every change gets typechecked, linted, tested and built, and then it checks that my row level security policies haven't regressed. That last one is the check I care about most. Access rules are the kind of thing that quietly loosen when you refactor, and you will never catch that by clicking around the app, so I treat it like any other test.

How it works

This is a React app, designed to run on both the web and as an Electron desktop app. Zustand is used for state management, and Supabase is a convenient choice for both the database and the backend at the same time. This is a super simple stack to work with, which helped me lots with development as this is my first large project like this!

Why I chose this stack

I chose to make it in React as webapps are a good universal option for both desktop and mobile users. It also meant I could port to desktop native easily without having to rewrite the codebase, and even opens options for an easier port to mobile with React Native in the future. Zustand was just a super simple state management library that I found easy to pick up, and runs very light compared to Redux with a nice hook-based architecture that fit my existing knowledge. I chose Supabase as it is a very simple and easy to use database solution, with a very generous free tier. I am also familiar with PostgreSQL so this made things easier.

Problems I hit

My main issue with this was designing a user interface. In the world of AI, proper design and UI/UX is more important than ever, as it requires a mix of both creative vision and real understanding of how people interact with computers. I had to go through so many revisions and do so much research to land on a good design system and UI/UX flow. I made an entire v1 of this app initially without this insight, but when it came to real testing I quickly found out that my knowledge was lacking, and was forced to do an entire rebuild of the structure and flow of the app.

What I would do differently

In hindsight, I definitely should've set up a proper dev workflow from the start, and spent a good amount of time at the start designing a full project spec and making sure the idea and feature set was solid and didn't shift. I spent so much time working with half ideas and developing in the dark, which just led to more and more rewrites. I was also a very big perfectionist, which for a first time project with no real public testing under my belt, was a recipe for disaster. In the future I will ensure solid product docs are in place, and prioritise real user feedback for refining my work.