PaperPilot!

This is a submission for the Hacktoberfest Open-Source AI Challenge Week 2: Side Hustle

I Built PaperPilot: Turning Previous-Year Question Papers into an AI-Powered Revision Plan

As an engineering student, I've learned that preparing for semester exams isn't just about studying the syllabus. It's also about figuring out what to prioritize.

Previous-year question papers can be incredibly useful, but going through multiple PDFs, finding repeated questions, identifying recurring topics, and organizing everything into a revision plan takes time.

So I decided to build something to make that process easier.

Meet PaperPilot, an AI-assisted exam preparation tool that turns previous-year question papers into a structured revision workflow.

My goal was simple: help students spend less time organizing their study material and more time actually studying.

What I Built

PaperPilot lets students upload previous-year question papers and helps them:

• Extract questions from PDFs, including scanned pages when OCR is configured.
• Find exact and similar questions across multiple papers.
• Identify recurring questions and analyze topic frequency.
• Review evidence linked to the original source papers.
• Generate a revision checklist and export useful results.

Instead of asking a generic AI chatbot to predict what might appear in an exam, PaperPilot focuses on evidence from the papers students already have.

It doesn't promise to predict future question papers. It helps students make more informed revision decisions using historical question patterns.

I built it primarily for engineering students, but the same idea could be useful for tutors, coaching centres, and students preparing for other examinations.

The side-hustle opportunity

Imagine a student with five years of question papers and only a few days left before an exam. PaperPilot helps turn that collection into something easier to navigate and revise.

A possible business model would be a free basic version with optional paid features for larger paper collections, advanced analytics, or additional revision tools.

That opportunity still needs validation. I haven't established that students are willing to pay, and finding out whether the tool genuinely saves them time is the next important step.

Demo

Try PaperPilot: https://mayukhjyotisarkar-hacktoberfest-week2app-bn7o6x.streamlit.app/

The intended workflow is straightforward:

1. Upload your papers.
2. Find recurring and similar questions.
3. Explore topic frequencies and source evidence.
4. Build your revision plan.

The hosted demo depends on the capabilities and dependencies available in its deployment environment. The local application supports optional Ollama-based AI inference and OCR when the required software is installed.

Code

GitHub repository: https://github.com/mayukhjyotisarkar/Hacktoberfest/tree/main/WEEK2

PaperPilot is built with Python and Streamlit, with separate components for document extraction, question processing, similarity analysis, data storage, and optional AI features.

How I Built It

I wanted to understand how the different pieces of an AI application work together instead of building just another interface around a remote AI API.

The first important decision was to keep the core question-analysis pipeline deterministic.

PaperPilot extracts text from PDFs, normalizes question text, uses TF-IDF and cosine similarity to compare questions, groups similar questions, and analyzes their recurrence across papers. SQLite stores the question-bank data, while Streamlit provides the user interface.

For the open-weight AI component, I integrated Qwen2.5-Coder 1.5B through Ollama to support optional features such as topic labeling for existing question groups and revision-note generation.

The AI doesn't replace the underlying question-matching system. Instead, it adds another layer to the workflow. Keeping these responsibilities separate means the core analysis doesn't depend on an AI response for every operation.

I also added OCR support for scanned PDFs. The application attempts ordinary text extraction first and can use OCR on pages that don't yield enough text. This introduced another practical challenge: Python dependencies alone aren't enough when an application also relies on external software such as Tesseract.

Along the way, I worked on the interface, local storage, setup scripts, dependency documentation, and automated tests.

One of my biggest takeaways was that building an AI application isn't just about choosing a model. The surrounding engineering — handling messy documents, validating outputs, managing dependencies, and explaining errors — is what makes the model useful to someone.

Why Does Open Innovation Matter?

For PaperPilot, open innovation means having more control over how AI is used, where it runs, and how the application can evolve.

A hosted AI API can be convenient, but repeated requests can introduce ongoing costs and a dependency on a provider's pricing, availability, and service policies.

Using an open-weight model through Ollama gives PaperPilot another option: run supported AI features locally instead of sending every request to a hosted model.

That matters in a few ways.

1. More control over recurring costs

Once the model is downloaded, local inference doesn't require a separate hosted-model API payment for every request. Hardware, electricity, and setup still have costs, but the economics can be more predictable for a small student-focused tool.

1. A more private local workflow

When students run PaperPilot locally and process their documents locally, their papers don't need to be sent to a third-party AI API for its local AI features. For students working with personal notes or institutions handling sensitive documents, that distinction can matter.

1. Freedom to experiment

I can evaluate alternative models, adjust prompts, and change how AI-generated labels and notes work without tying the entire application to one hosted provider.

1. Independence from a single AI service

The core similarity and recurrence analysis works separately from the language model. That reduces the extent to which the primary workflow depends on an external AI service being available.

Open-weight models aren't automatically better at every task. They have hardware requirements, setup complexity, and their own quality limitations. Model licences also matter, and the permissions associated with a particular model should be checked before redistributing or commercially using it.

There's another important distinction: the public Streamlit demo runs in a remote hosting environment. Its privacy and offline characteristics aren't the same as running the application entirely on your own computer.

For me, the value of open innovation isn't simply that a model is available to download. It's that I can make deliberate choices about cost, privacy, deployment, and model behavior while building a tool for a specific problem.

What I Learned

PaperPilot taught me that a useful AI product doesn't need to put a language model at the centre of every operation.

Sometimes, traditional text-processing techniques are better suited to the core task. Sometimes, a language model adds value on top. Knowing where to use each approach is part of the engineering.

I also learned that supporting real documents is messy. PDFs can contain unusual layouts, scanned pages, broken text extraction, and inconsistent question formatting. A feature that works on a clean sample isn't automatically ready for every student's material.

And passing tests is only one milestone. A tool can be technically functional without necessarily being useful enough for someone to adopt or pay for.

What's Next?

The next milestone for PaperPilot is real-world validation.

I want to see how it performs on different university question papers, whether students find the recurring-question analysis useful, and what they would change after using it.

From there, I can prioritize improvements based on actual needs rather than adding features just because AI makes them possible.

PaperPilot started as a way to solve a problem I understood personally. Building it has also been an opportunity to explore open-weight AI, local inference, document processing, and the engineering required to turn an idea into a usable application.

The goal now is simple: make it genuinely useful to the students it was built for.

Built for students. Powered by Python, traditional text analysis, and optional local open-weight AI.