reTeach

reTeach turns a syllabus into a 2-minute diagnostic, then emails each student a tight, personalized resource pack and gives teachers clear gap dashboards so classes catch up fast and don’t stall.

Comment

Inspiration

Our AP Calculus BC class gave us ~50 hours of summer work and still fell months behind. In class, some students were bored because they already knew the material, and others were completely lost. By spring, the pacing was so off that we weren’t really prepared for the AP exam.

We built reTeach because that system is broken. The point of school is to learn, not to hope everyone magically shows up with the same background. If you're behind, you need targeted support, not shame. If you're ahead, you shouldn't be punished with busywork.

We also looked at “AI school” models like Alpha School, which costs around $50K/year and expects the student to basically learn from an AI while the human teacher is more of a monitor. That’s not realistic or accessible. We wanted something that:

  • personalizes without replacing the teacher
  • works in normal public school classrooms
  • doesn’t cost $50K

What it does

reTeach gets every student in a class to baseline:

  1. The teacher uploads their syllabus.
  2. Our LLM parses it and extracts all explicit and implied prerequisite concepts.
  3. We automatically generate a short Yes / Maybe / No diagnostic on those topics. It’s fast and low-pressure.
  4. The teacher shares the diagnostic with the class via QR code or link.
  5. Each student fills it out. Right after submitting, they get an email with a focused set of study resources customized to what they’re missing (videos, walkthroughs, textbook-style explanations, etc.).
  6. The teacher gets dashboards with:
  • weakest topics
  • strongest topics
  • % understanding by concept
  • classwide vs individual needs

Students get what they personally need to catch up (or move ahead without busywork). Teachers get data they can actually use to adjust pacing and target the real gaps.

How we built it

Pipeline

  1. Syllabus ingestion The teacher uploads a syllabus. We preprocess it (chunking, cleaning) so we can pass high-signal slices to the model instead of dumping the entire thing.

  2. Topic extraction + diagnostic builder We prompt the model to infer both stated and implied prerequisite skills. Then we generate a Yes / Maybe / No diagnostic that probes those skills without turning into a full test.

  3. Student delivery We generate a QR code or link so the teacher can distribute the diagnostic easily. Students answer on their phones. We map each student’s weak topics automatically.

  4. Resource aggregation An agent does constrained search across trusted domains (for example, Khan Academy), plus indexed textbook content, and assembles a short “fix these first” pack for that specific student. We cut out dead links, 2-hour videos, and off-topic filler.

  5. Email dispatch Each student is emailed their resource pack right after submission. We initially tried SMTP from platforms like Vercel/Railway and hit security restrictions, so we migrated to SendGrid for reliable delivery.

  6. Teacher analytics We generate both class summaries and per-student breakdowns so teachers can focus review where it matters and stop wasting time reteaching what half the class already knows.

Under the hood

  • prompt engineering for syllabus parsing
  • context chunking to get around LLM context limits and keep answers focused
  • constrained retrieval for resource quality
  • service-side email and analytics for teachers

Challenges we ran into

1. Extracting implied prerequisites from syllabi

Teachers almost never list all the assumed background. For example, “Unit 1: Limits” silently assumes algebra fluency, trig identities, etc. Early on, the model either missed those or invented random skills. That made the diagnostics useless.

Fix: better prompting + preprocessing. Instead of feeding the entire syllabus at once, we feed targeted, cleaned slices so the model focuses on the right context.

2. Bad resource quality from naive search

The first version of our resource finder was basically “LLM, go search the web.” Results included:

  • 2-hour YouTube videos
  • dead sites
  • content that wasn’t actually on-topic

Fix: we added constraints. We enforce max video/article length, prioritize trusted domains, and define what a “good resource” looks like. After that, we got short, accurate, relevant resources students will actually use.

3. Email delivery limitations

Hosts like Vercel and Railway limit SMTP for security reasons, which blocked us from emailing students directly at scale.

Fix: we moved to SendGrid so each student can still immediately get their custom resource pack.

4. LLM context limits

Some syllabi are enormous. Dumping long documents into the model actually made the output worse, not better.

Fix: we chunk and prioritize. The model only sees the relevant parts tied to prereq skills, which makes topic extraction cleaner and keeps the diagnostic focused instead of noisy.

5. Making dashboards meaningful

Teachers don’t want 40 analytics widgets. They want: “Your class is weak on X. Spend tomorrow on X.” We had to design our reporting around actual decisions a teacher will make in the next class period, not vanity metrics.

Accomplishments that we're proud of

  • We can take a normal teacher syllabus, auto-generate a clean diagnostic, and personalize support for every student in that class without asking the teacher to build any of it by hand.
  • Students get targeted, usable resources instantly after submitting the diagnostic. No guessing what to Google, no “ask a tutor.”
  • Teachers finally get early signal: who’s behind, in what areas, and how badly. They can adjust pacing before the class derails for the whole year.
  • We kept the teacher in charge. AI is doing triage and prep work, not replacing instruction.

What we learned

  • Depth > breadth. Making “diagnose gaps and send high-quality resources” actually good matters more than shipping a long list of half-finished features.
  • Simplicity in UX is not optional. Students won’t engage with something that feels like extra work. Teachers won’t adopt something that feels like setup overhead.
  • LLMs work best with tight, high-signal context and a clearly scoped job. They get worse when you hand them 20 pages of messy input and say “figure it out.”
  • Students are the real customer. If they don’t open the email or can’t use what’s inside it, the whole system fails.
  • Documentation is leverage. Not documenting early was a mistake. We wasted time digging through other people’s code and guessing why something existed. Once we started writing internal notes and reasoning as we went, everything sped up: debugging, onboarding, shipping.

What's next for reTeach

Better resource generation

We want to widen our resource search space and allow the agent to browse more freely, but keep smart constraints (trusted domains, max length, relevance checks). The goal is an even tighter, more on-target resource set for each student.

Teacher-facing controls

We plan to add more tools for teachers:

  • fine-tune or regenerate quizzes that directly target the gaps we’ve identified
  • upload past quizzes so reTeach can build study guides and practice material aligned to what will actually be on the test
  • auto-generate new quizzes on demand

This closes the loop between “we found the gap” and “here’s how you assess and fix it in class tomorrow.”

Technical hardening

We plan to:

  • move heavy work and system prompts into async jobs/queues to keep request handlers fast
  • add rate limiting by IP
  • add smarter caching where it matters
  • continue tightening security (we already use CSPs, key rotation, and guardrails against SQL/file injection, but security is never ‘done’)
  • formalize observability and delivery: centralized logging, metrics, distributed tracing, CI/CD with linting, unit/integration tests, and SAST/DAST gates

The goal is to keep shipping fast without shipping unsafe.

Built With

Share this project:

Updates

Submission history