Challenges and Solutions

Supabase RLS policies

Problem: Supabase's Row Level Security (RLS) policies prevent unauthenticated users from inserting data into tables like profiles. But new users need a profile row created before they can authenticate. This meant new users couldn't create profiles because they weren't authenticated, but couldn't authenticate without a profile existing.

Even authorizing them before the row insert failed to work due to the latency, and they would theoretically be stuck out forever, not being able to authorize themselves...because they weren't authorized.

Why it mattered: New user registration was completely broken. Every signup attempt failed with permission errors, making the platform unusable for anyone beyond the initial test account. What's the point of a website if people can't use it after all?

Solution: Instead of using Supabase for cloud storage, I connected Postgres SQL to Django, and made a local database with the tables "Profiles" and "Quizzes". This allowed for hassle-free row inserts and smooth authorization

---

Quiz Parsing

Problem: No matter what prompt was used, Gemini did not always follow it and occasionally returned textual response which broke the quiz generation since using json.loads() failed instantly. Manually parsing and structuring into dictionary containing lists could be done, but there still wouldn't be surety about the structure of the response.

Why it mattered:

Users would upload study materials, wait for processing, then just get hit with an error, confused about what just happened, this didn't happen always, but in random, unpredictable ways, which made it even more crucial to solve.

Solution:

After a LOT of googling, I came across the documentation that actually gave me what I needed. Now, the model returns only and only a JSON object every time.

---

Lack of actual data

Problem: The progress page visualizes up to 30 quizzes with metrics like average accuracy, best performance, improvement trends, and daily streaks. But I did not have actual data to represent. The frontend was ready to receive jinja variables, the backend already collected info through the database, but what do I visualize when there's nothing to visualize? Taking 30 quizzes myself would require hours of work, and demonstrating the streak feature would require me to go back in time, both of which were impossible.

Why it mattered: Without representative data, I couldn't showcase one of Saathi's core features in demos or screenshots. Judges and users wouldn't see the motivational value of progress visualization, which defeats the purpose of building it in the first place.

The Solution:

After creating the progress view that would render the HTML with the visualization, I overwrote the same function intentionally to send hardcoded values as context instead solely for the sake of demonstration. In a real production setting, this function could easily be removed and the website would work just as normal