Studyback — Turn Your Old Study Materials Into a Personal AI Teacher
Inspiration
Students often have plenty of study materials, but that does not necessarily mean they have an effective way to learn from them again.
Lecture slides, PDFs, and notes tend to accumulate over time. When preparing for an exam or revisiting an old subject, students have to figure out what to study, ask questions themselves, find practice problems, evaluate their own answers, and decide which topics they still do not understand.
We wanted to build something that goes beyond a chatbot that simply waits for a question.
That idea became Studyback: an AI teacher that understands a student's own study materials, teaches concepts, tests understanding, identifies weak topics, and guides the student back to what they need to review.
The core learning loop is:
Learn → Test → Evaluate → Review
Instead of ending after one conversation, Studyback keeps a learning state so students can return to the same material and continue learning based on their previous progress.
How We Built It
We designed Studyback as a web-based AI learning workspace.
A student starts by uploading a study material. Studyback extracts the text, cleans and chunks it, identifies topics and subtopics using AI, and organizes everything into a Material Library.
From there, the student can start a study session and choose how they want to learn:
- Teach Me — receive explanations and ask follow-up questions.
- Quiz Me — test understanding through structured questions.
- Review Weak Topics — focus directly on topics with low mastery.
- Guided Study Session — combine the complete learning loop into one adaptive experience.
All of these modes live inside the same Studyback Workspace rather than sending the user between separate pages. The workspace also includes a Learning Map that shows the student's mastery and learning status for each topic and subtopic.
Technically, we chose a modular monolith architecture because this project had to be built within a 48-hour hackathon. The application uses React for the frontend, Laravel for the backend, and PostgreSQL for persistent application state.
For AI, we built an in-process ai_service abstraction that separates AI reasoning from application logic. The default provider is OpenRouter using the openrouter/free route, while Featherless.ai is supported as an optional provider.
We intentionally avoided adding a vector database for the MVP. Instead, Studyback retrieves relevant chunks by filtering them by material and topic/subtopic in PostgreSQL. This keeps retrieval simple and appropriate for the single-material, topic-focused learning experience we designed.
One Important Design Decision
One of the most important architectural decisions we made was separating AI reasoning from learning state.
The AI can explain concepts, generate quizzes, and evaluate answers, but it does not directly decide whether a student has mastered a topic or write learning state to the database.
The application owns mastery, status, scoring, and persistence. This prevents an AI response from silently corrupting a student's progress and gives the learning system deterministic state management.
This distinction became especially important when implementing the adaptive learning loop. A quiz result can update mastery, identify a weak topic, trigger a review, and eventually lead to a re-test and an updated learning state.
Challenges
Building an Adaptive Learning Experience in 48 Hours
The biggest challenge was balancing ambition with the reality of a 48-hour hackathon.
We had to resist the temptation to build unnecessary infrastructure. Instead of microservices, vector databases, background workers, or a standalone AI service, we kept the MVP focused on a modular monolith with clear internal boundaries. The architecture was intentionally designed so these components could be introduced later without requiring a complete rewrite.
Keeping AI Grounded in the User's Material
Another challenge was making sure Studyback behaves like a teacher for the uploaded material rather than becoming a generic chatbot.
We therefore designed retrieval around the current material and topic. Relevant chunks are selected from PostgreSQL before the AI request is made, and the AI receives those chunks as its context.
This makes the learning experience centered around what the student actually uploaded.
Connecting AI Evaluation to Real Learning Progress
Generating an answer evaluation is relatively straightforward. Turning that evaluation into meaningful learning progress is more complicated.
We needed to connect:
Quiz → Evaluation → Score → Topic Mastery → Weak Topic Detection → Review → Re-test
without allowing the AI itself to become the owner of application state.
This led us to make the Learning State Engine deterministic while using AI only for reasoning tasks.
What We Learned
Building Studyback taught us that an AI application is not just about choosing a model and sending prompts.
The surrounding application architecture matters just as much.
We learned how to:
- Design an AI feature around a concrete user workflow rather than a generic chatbot.
- Separate AI reasoning from deterministic business logic.
- Build a lightweight retrieval system without immediately reaching for a vector database.
- Validate structured AI output before allowing it into application logic.
- Design an adaptive learning loop where user interactions influence future learning.
- Make architectural trade-offs based on the constraints of a real 48-hour hackathon.
Most importantly, we learned that AI becomes much more useful when it is part of a system with memory, state, and a clear purpose.
Studyback is our attempt to turn static study materials into an ongoing learning experience — one where the AI does not simply answer questions, but helps students understand what they know, what they do not know, and what they should learn next.
Built With
- ai
- css
- docker
- javascript
- laravel
- llm
- php
- postgresql
- rag
- react
- rest
- tailwind
- vite

Log in or sign up for Devpost to join the conversation.