LectureAI

01Build

The pipeline took a raw lecture recording and produced structured study notes: FFmpeg audio processing, transcription, then LLM-based structuring into summaries and study materials, run asynchronously through a Celery task queue over Redis, because an hour-long lecture doesn't process inside an HTTP request. A Python backend with Alembic-managed migrations, a React frontend, and the operational glue between them. I led full-stack development end to end.

The technically interesting decision was splitting correction from summarisation. A summariser fed a corrupted transcript produces a clean, well-organised summary of the wrong thing, so we used lecture slides as reference material to fix technical terminology in the transcript first, then summarised. Error propagation is a pipeline design problem, not a model problem.

02Discovery, and what it said

I ran customer discovery across NUS student cohorts while we built. Two walls emerged. The soft one: students liked the output, said so enthusiastically, and then didn't change their study workflow or show willingness to pay at sustainable unit economics, interview enthusiasm and retention behaviour told different stories, and retention was telling the truth. The hard one: lecture recordings contain other students' voices, which in Singapore triggers real data-protection consent requirements. Every adoption conversation risked becoming a legal conversation first.

03The wind-down call

We chose to stop rather than drift, a decision made when the evidence was in, not when the money ran out. What I'd do differently: run pricing and willingness-to-pay tests before building the full pipeline, not after. Talking to users is not the same as watching what they do.