AudioScholar

Overview

AudioScholar was my undergraduate capstone, but I wanted to treat it as a real product instead of a school deliverable. The premise was straightforward - lectures contain a lot of useful material that students rarely revisit because rewatching or rereading is expensive. I wanted to build something that would make lecture content searchable, summarizable, and recommendable, so a student could find what they actually need without scrubbing through hours of audio.

The product surface

The Android client handles recording and uploading, with care taken to keep audio quality high enough for transcription without bloating storage. A web dashboard built in React surfaces transcripts, AI-generated summaries, and topic-based recommendations. The backend coordinates everything - audio storage, transcription pipelines, summarization with content-aware prompts, and recommendations that connect lectures with related material. The split lets each part stay focused on what it's good at.

Working under capstone constraints

What made this project interesting was not the AI layer. It was building a system that had to be demonstrable, defensible, and stable on a deadline. Capstone reviews are unforgiving - if your transcription pipeline is flaky during a live demo, the rest of the work doesn't matter. I spent a lot of time on the boring infrastructure - retry logic, queue handling, file lifecycle, error surfaces in the UI - because those were the things that decided whether the product looked credible.

What I learned

The biggest takeaway was that AI features feel like the project, but they're not. The transcription, summarization, and recommendation pieces only worked because the surrounding system was reliable. Building AudioScholar reinforced something I keep coming back to in later work - the model is rarely the constraint. The constraint is usually the seam where the model meets storage, networking, and a user who needs to trust the result.