A HackHazards '26 submission
Most "AI tutoring" apps are chatbots wearing a mortarboard. They answer questions when asked, but they have no memory of how a student learns over time — whether a topic that was "mastered" last week is quietly decaying, whether a student is avoiding a chapter because it's hard or because they're bored, or whether a right answer today was actually a lucky guess.
For ICSE/CBSE students specifically, this matters a lot. The syllabus is dense, exam cycles are unforgiving, and the difference between a B and an A often comes down to catching a weak concept three weeks before the test instead of the night before. I built StudyMate AI to solve that: not another Q&A bot, but a system that tracks a student's cognitive state over time and adapts accordingly — using voice as the primary interface, because most students don't want to type out a doubt at 11 PM, they want to just ask. Sarvam AI — StudyMate leans on Bulbul V3 and Saaras specifically because generic Western TTS/STT stacks handle Indian English and code-switched speech (Hindi-English mixing mid-sentence, which is how most ICSE/CBSE students actually talk) noticeably worse. This wasn't a checkbox integration; voice quality directly determines whether a student trusts the tutor enough to keep using it. StudyMate was subsequently accepted into the Sarvam Startup Program on the strength of this integration.
The core design decision was refusing to treat "correct/incorrect" as the only signal. Every attempt a student makes updates a behavioral graph in Neo4j, and each student gets classified into one of four states per topic:
This is why a graph database made more sense than a relational one: mastery isn't a single row's property, it's a relationship between a student node, a topic node, and a time-decayed weight on the edge between them. Cypher queries traverse these relationships to answer questions like "which topics is this student avoiding that are also prerequisites for a topic they're struggling with" — a query that's painful in SQL and natural in a graph.
The 8-thread parallel Cypher execution exists because classification has to run across the entire topic graph for a student on every session start, not just the topic they're currently on — otherwise the spaced-repetition scheduler doesn't know what to resurface.
Expo/Node dependency hell. Mid-development, the app started throwing MODULE_NOT_FOUND
on SDK 54. The instinct is to assume an SDK/Node version mismatch (Node v26.4.0 was a live suspect), but the actual root cause was stale node_modules
from an earlier Expo version — a full reinstall resolved it. The lesson: don't assume the exotic explanation before ruling out the boring one. Voice pipeline latency under load. Chaining STT → LLM → TTS naively introduces enough round-trip latency that a "voice-first" tutor starts to feel laggy and unnatural. Getting this to feel conversational required treating the pipeline as three independently optimizable stages rather than one black box.
Avoiding false "mastery." Early versions of the classification logic over-rewarded speed, which meant a student who guessed quickly and got lucky could get marked "Mastering." The fix was weighting classification against variance in response pattern, not just accuracy — a lucky guess looks statistically different from real recall even when both are "correct."
The HackHazards submission (README, Gamma pitch deck, CodeRabbit-reviewed codebase) is the checkpoint, not the finish line. With Sarvam Startup Program backing, the next phase is expanding the topic graph's coverage and tightening the avoidance-detection heuristics, since that signal — a student silently avoiding a topic — is the one traditional apps miss entirely and the one that actually predicts exam-day surprises.
*Built for HackHazards '26. Live demo: