Socratic

Explore Page
Question Board Page
Posting your Topic
Settings
Match Session
Friend Tab

Inspiration

Every student has had the same night: stuck on one specific concept, too late to email a professor, too specific a question for a generic search result — and even then, the "help" online doesn't understand what you're going through mentally. You feel alone, not just because you don't understand the concept, but because there's no one there to be confused with you. Socratic aims to close that gap: giving students not just the tools to learn a concept they're stuck on, but a way to connect with someone else who needs that human connection while learning, too.

What it does

Socratic lets students (verified via their school email — see env.example to set it up) describe what they're struggling with in plain language. That input is classified against a real topic taxonomy and matched with another student currently stuck on the same concept, at a similar self-rated proficiency level — not just enrolled in the same course. If no peer is available, an AI tutor steps in immediately instead of leaving the student with nothing.

Either way, the pair lands in a real-time shared workspace built specifically around Socratic pedagogy — the AI asks guiding questions instead of supplying answers, so working through the problem is unavoidable rather than optional.

Core features:

Struggle-based peer matching, scoped to the specific concept a student is stuck on, not just their course
AI tutor fallback when no peer is available, using guided questioning rather than direct answers
Real-time shared workspace: synchronized whiteboard, notes, and chat
Mutual-consent publishing — a session only goes into the public solutions archive if both participants agree
Friends/DM system and a public question board for offline help
Safety layer: .edu email verification, bidirectional blocking enforced across every contact surface, reporting, avatar-based profiles instead of required photos

We deliberately scoped this first version toward college students, using .edu email verification, no location data collection, and no required profile photo as deliberate safety choices. One limitation worth being upfront about: .edu domains aren't exclusively held by colleges. EDUCAUSE's current policy restricts new .edu registrations to postsecondary institutions, but many K-12 districts registered .edu domains before that policy tightened and still hold them today — meaning .edu verification confirms school affiliation, not age or enrollment level. A production version would need an explicit age gate layered on top of email verification before expanding contact features like messaging further; we're flagging this as a known, disclosed gap rather than overstating what school-email verification alone guarantees.

How we built it

We split the AI workload deliberately rather than routing everything through one model. A self-hosted, local scikit-learn classifier (TF-IDF vectorization + cosine similarity against a topic catalog) handles the large majority of requests — topic classification, input moderation — with no external API call and latency measured in single-digit milliseconds. A hosted, larger reasoning model (Groq, Llama-3.3-70B) is reserved for the parts of the product that need deep reasoning: the Socratic tutoring dialogue itself, and the small subset of ambiguous inputs the local classifier can't confidently resolve.

Matching runs on a real, tested algorithm rather than a keyword filter: each student's struggle is tracked per-topic rather than as one overall skill score, matches require actual overlap on the specific topic a student is currently working on, and proficiency gating keeps pairs within a bounded skill gap.

The rest of the stack: a FastAPI backend over WebSockets for real-time whiteboard/chat sync, a React frontend, PostgreSQL for persistence, deployed on Netlify (frontend) and Render (backend + database). The rest of the stack: a FastAPI backend over WebSockets for real-time whiteboard/chat sync, a React frontend, PostgreSQL for persistence, deployed on Netlify (frontend) and Render (backend + database).

Challenges we ran into

Some of the hardest problems were the ones that forced us to correct our own claims before they shipped, technical and privacy-related alike. We found and fixed a real concurrency bug in our request-batching logic — a task that, on inspection, was cancelling itself mid-execution. Later, after building a batching layer meant to consolidate expensive model calls, we found our topic-classification step was already sub-millisecond on its own (batching it would only add latency for no real benefit), so we left it out rather than keep a feature that looked impressive but didn't actually help. We also caught an early "multimodal" quality-inspection claim before it shipped, confirmed the model behind it was text-only, and fixed the framing.

On the product side, the harder problem was balancing feature scope against privacy. It was easy to keep adding features, but we had to be deliberate about which ones actually needed to exist versus which ones introduced risk without enough value: enforcing .edu emails, adding chat content filtering, and giving users real control over who can contact them were the pieces we treated as non-negotiable rather than nice-to-haves.

Accomplishments that we're proud of

We’re proud of how intentionally we approached the design of the app. We built the AI architecture so each model handles the tasks it’s best suited for, balancing capability and cost. We also tested our matching algorithm against real edge cases, including one where the highest-similarity candidate was passed over because they didn’t share the specific topic that mattered. Finally, we made safety part of the design from the beginning, with school-email verification, optional avatars instead of required photos, no location collection, and blocking enforced throughout the app.

What we learned

The biggest lesson wasn't a specific technical trick, it was a habit: check your own claims before you make them. More than once, something we assumed was working (or assumed was a real improvement) turned out not to hold up once we actually tested it, and fixing that mattered more to the final product than any single feature did.

What's next for Socratic

Expanding the topic taxonomy and matching to more courses and subjects; upgrading topic classification from TF-IDF to real semantic embeddings for better handling of phrasing our current classifier doesn't recognize; extending quality inspection of whiteboard work to real multimodal analysis now that we've scoped it accurately; adding an explicit age-affirmation gate on top of email verification, since .edu alone doesn't guarantee postsecondary enrollment; and, if we ever pursue a version for younger students, building a genuinely different, school-supervised safety model rather than adapting this one.

We're submitting this primarily for AI for Education. Socratic's whole design is built around a pedagogical principle, guided discovery over direct answers, not just AI applied to a study app. We also think the project has a real shot at Best Use of Machine Learning and Conversational AI, given the tiered classification/reasoning architecture and the AI tutor's dialogue design.