Pumpkino AI

Know what to study next, not just what percent you know.

Comment

Inspiration

This summer, Y Combinator published a set of requests for startups covering where they see AI heading next. One of them, written by Tom Blomfield, was called "Company Brain." His argument was that companies aren't struggling to use AI because the models aren't good enough anymore. They're struggling because their knowledge is scattered across Slack threads, old email chains, support tickets, and people's heads. No AI agent can act reliably on knowledge it can't find or structure.

That idea stuck with us, but not because we run a company. We're students. And it turns out the exact same problem shows up in how we study. A semester's worth of understanding lives across scattered lecture slides, handwritten notes, a few PDFs of past exams, and whatever you remember from a professor saying something once in class. Most AI study tools treat that mess the same way a basic chatbot treats any question: you ask, it answers, and it forgets the shape of what you actually know five minutes later.

We wanted to try applying Blomfield's idea literally. Not a chatbot with your notes pasted into the context window, but something closer to what he described: a structured knowledge base, purpose built for one person's course material, that an AI can actually reason over instead of just search. That's where Pumpkino AI came from.

What it does

Pumpkino AI turns a student's course materials into a living, structured knowledge graph, then uses that graph to decide what a student should actually focus on, not just to answer whatever they type into a chat box.

Here's the core loop. A student uploads their materials for a subject: lecture notes, slides, past exams, whatever they have. Instead of just indexing that text for retrieval the way a typical RAG chatbot would, Pumpkino extracts the actual concepts inside it and the prerequisite relationships between them. So if a document covers derivatives and then convexity, the system understands that convexity depends on derivatives, not just that both words appear somewhere in the same PDF.

Every concept gets a mastery score, built from quiz performance, from how a student answers when asked to explain a concept back in their own words, and from patterns noticed during chat conversations. But the interesting part isn't the score itself. It's what the graph does with it. Instead of showing a flat percentage, Pumpkino computes leverage: which weak concept is blocking the most other concepts downstream. That becomes the single highest priority thing to study, front and center on the dashboard, instead of a wall of equally weighted percentages that don't tell you anything about where to actually start.

The system also reads uploaded corrected exams specifically for style, not just content. It picks up on how a particular teacher actually grades: whether they favor open ended proof questions, whether they give partial credit for a sound method even with a wrong final answer, what kind of mistakes get penalized hardest. That gets surfaced back to the student as a genuine, source cited profile of how their own teacher works, something no generic study tool has any way of knowing.

The AI tutor is grounded in the same graph. When a student asks a question, it isn't answering from a blank slate. It can trace a wrong quiz answer backward through the prerequisite chain to find the actual root cause of confusion, sometimes several concepts upstream from where the mistake showed up. It remembers recurring confusion across sessions instead of treating every conversation as new. And it can generate quizzes, tests, or flashcards on demand, built from the student's real material and, where relevant, shaped by that teacher's actual grading style, not pulled from a generic question bank.

Beyond individual studying, Pumpkino extends into shared study groups. A group pools everyone's uploads into one shared graph, so if one student misses a lesson, someone else in the group has probably already covered that gap with their own notes. The group's AI agent can be tagged directly inside a group chat, joining the conversation the way a person would, or reached privately for one on one help grounded in the same shared context. A lightweight matchmaking system also looks at who's strong where in the group and who's struggling, and can nudge two students to connect directly.

How we built it

The frontend is React with Vite, styled around a deliberately restrained, ink on white design system we developed specifically to feel like a calm study tool rather than a typical flashy AI product. Color is used functionally for status and focus, never decoratively.

The backend is Node and Express, backed by Supabase for the database, authentication, and file storage. The most technically interesting part of the backend is the LLM routing layer. Since this was built on free tier API access across several providers, we didn't want to just call one model for everything. Instead we built a router that assigns different tasks to different providers based on what each is actually good at and how expensive each call is likely to be. Gemini Flash handles concept extraction and diagnosis, since it's fast, free at meaningful volume, and reliable at structured JSON output. Groq runs live chat, since speed matters most in a real time conversation. Claude handles the more premium generation tasks, like producing practice questions in a specific teacher's style, where quality visibly matters more than volume. OpenRouter sits underneath all of it as a fallback if a primary provider fails or gets rate limited.

The concept graph itself is stored as a proper relational structure, not just a blob of embeddings. Concepts, prerequisite edges, mastery scores, and confusion notes are all real rows in Postgres, which is what makes the leverage calculation possible in the first place. It's a straightforward graph traversal over real data, not something we're asking an LLM to guess at on every page load.

We iterated on the UI heavily using an AI assisted design workflow, running two parallel development tracks, one for backend and one for frontend, prompted from a single planning conversation so both sides stayed in sync as the product's scope grew.

The full stack is deployed with the frontend on Vercel, the backend on Railway, and Supabase handling data, auth, and storage in between.

Challenges we ran into

Getting the deployment pipeline working correctly took longer than expected. We hit a chain of small but blocking issues: environment variables missing the required Vite prefix so the frontend silently couldn't reach Supabase, a backend port mismatch between what Railway's proxy expected and what our app was actually listening on, and a malformed backend URL missing its protocol that caused every API call to silently 404 instead of failing loudly. Each one produced a slightly different, confusing symptom on the frontend, which made root causing them properly, one at a time, more important than guessing.

We also ran into a real Supabase quirk during demo data seeding. Manually inserting rows into auth.users outside the normal signup flow left several token columns as null instead of empty strings, which silently crashes Supabase's admin API in a way that's not obvious from the error message alone.

On the product side, the harder challenge was resisting the urge to build a generic chatbot wrapper and calling it done. It would have been much faster to just build a chat interface on top of uploaded PDFs. Building the actual structured graph underneath it, and making the leverage calculation, the teacher profile extraction, and the root cause tracing all genuinely work off real relational data instead of being faked for the demo, took a lot more of the build time, but it's the entire reason the product is different from what already exists.

Accomplishments that we're proud of

We're proud that the leverage calculation is real. It's not a static label or a cosmetic ranking, it's a genuine graph traversal that looks at which concepts are prerequisites for others and which of those downstream concepts are still unmastered, computed fresh from actual data every time.

We're proud of the teacher profile feature specifically, because as far as we know nothing else in this space attempts it. Most AI study tools are generic across every student using them. This one reads a specific teacher's specific corrected exams and surfaces genuinely useful, source attributed patterns about how that one teacher grades.

We're proud that the multi-provider LLM routing actually holds up under real, uncontrolled usage, including automatic fallback if a provider fails or a free tier limit gets hit, which matters a lot when the whole system is running on shared free API keys during judging.

And we're proud we kept pushing the product scope even under a tight deadline, going from a solo study tool to a genuinely collaborative shared knowledge graph for study groups, complete with an AI agent that can be brought directly into a group conversation.

What we learned

We learned that AI generated time estimates during planning are consistently, wildly conservative. Features we scoped as multi day efforts were often done in a couple of hours once we had the right prompt and the right existing infrastructure to build on top of.

We learned that clear, narrow, specific prompts to an AI coding assistant produce dramatically better results than broad ones. Early in the project, vague instructions like "make the UI better" led to inconsistent, sometimes contradictory changes across different screens. Naming the exact component, the exact behavior, and the exact before and after state got far more reliable results.

We learned a lot about the real tradeoffs of multi provider LLM routing in practice, not just in theory. Picking the right model for a task based on latency, cost, and output quality, and building a fallback chain that actually degrades gracefully instead of failing loudly, is a genuinely different discipline from just calling one API everywhere.

And on the deployment side, we learned to verify claims instead of trusting them. More than once, a change was reported as tested and working when it hadn't actually been exercised against a live server. Building the habit of demanding a real curl request or a real screenshot before accepting something as done saved us from shipping broken features more than once.

What's next for Pumpkino AI

Right now, Pumpkino answers and reacts. The next real step is making it act on its own initiative, closer to an agent than a chatbot. Concretely, that means the system proactively generating a practice test on its own a few days before a flagged exam date instead of waiting to be asked, the AI posting a matchmaking suggestion directly into a group chat when it notices a clear opportunity for peer teaching instead of only surfacing it passively on a dashboard, and its memory of a student's recurring confusion actually changing how it teaches next time, not just being something it can recall.

We also want to bring corrected test uploads into the leverage and teacher profile systems even more deeply, using them as calibration data so generated practice questions get closer and closer to matching a specific teacher's real exam style over time.

Longer term, we want to bring Pumpkino to iOS. A native app opens up push notifications for things like an upcoming test or a groupmate's matchmaking suggestion, offline access to a student's own knowledge graph, and a much better mobile studying experience than a responsive web app can fully deliver, especially for quick flashcard or quick check sessions between classes.

Built With

Share this project:

Updates