Summary

• Unified Student Ecosystem: Consolidated two separate student projects into a single platform, eliminating fragmentation and improving the academic planning experience for SMU students.
• Deterministic Pipeline Overhaul: Replaced early code and unreliable LLM parsers with a deterministic seven-step heuristic pipeline, offline CatBoost machine learning models.
• Embedded Serverless MCP: Deployed a shared catalog inside Next.js serverless functions with seven interactive UI views, eliminating dedicated server costs while supporting both an in-app assistant and external AI clients.
• Sustainable AI Economics: Built a quota engine and off-topic denylist to support thousands of students with a small monthly budget without commercial advertisements.

Introduction

Back when I was a second-year university student, I was exploring certifications to learn more about data science and machine learning. To apply what I was studying to a practical problem, I started building an independent project called BidlySMU, which later became BOSS Bidlytics. The idea was simple: help Singapore Management University (SMU) students navigate the university course bidding system with transparent data and predictive analytics.

The maintainer of AfterClass noticed the work I was doing and asked if I would be interested in contributing directly to AfterClass. When I was a first-year student, I had relied heavily on AfterClass to research courses and professors. I knew firsthand how high the potential of the platform was, and contributing directly offered a way to deliver helpful data and planning tools straight to an established community of thousands of students. Since then, I have been contributing features and improvements whenever I have the capacity.

During this journey, one pattern in the university developer community kept standing out to me. Many talented students choose to build completely separate, standalone websites for their utilities rather than contributing to an existing open-source project. Building your own tool is understandable. It lets you choose your own tech stack, direct the roadmap, and showcase a shiny repository on your resume.

The drawback is that once these tools are released, the student community is left with different bookmarks for separate tools: one for timetable generation, one for bidding statistics, one for graduation roadmaps, and one for course reviews. Students end up switching across multiple tabs just to plan a single term. Furthermore, student maintainers eventually graduate, leaving these fragmented websites unmaintained until their domain names expire.

Rather than creating yet another independent tool, the better path forward was clear: unite these efforts under one roof. AfterClass release 1.5.0 represents a complete engineering overhaul that brings together three major student-led projects, establishes an automated data pipeline, and embeds a Model Context Protocol (MCP) server directly into our web infrastructure.

Data Scraping Pipeline

BOSS Bidlytics did not begin with a clean, modular architecture. In the early stages, I prototyped the initial pipeline by prompting through ChatGPT Web.

While that approach helped stand up an initial prototype quickly, it introduced significant technical debt. The generated Python scripts were procedural, heavily bloated, and packed with unnecessary fallback branches and nested blocks. When an edge case occurred, the code would silently swallow errors or fall back to legacy data paths, making debugging difficult.

The most brittle component was our professor name extraction. Bidding records from the university portal format instructor names in inconsistent shorthand. In early iterations, the pipeline called Google's Gemini Flash API via network requests to parse and extract surnames from raw strings. This introduced network latency, rate limits, ongoing API expenses, and unpredictable naming variations that broke relational database joins.

To fix this, we conducted a full pipeline rewrite in the boss-bidlytics repository, transitioning the system into an object-oriented ETL engine governed by a central coordinator.

We completely removed the LLM dependency from the data pipeline and replaced it with a deterministic heuristic resolver coupled with a curated lookup table (professor_lookup.csv). The new resolver checks exact database matches, known aliases, surname prefixes, hyphenated compound names, and normalised initials. It delivers consistent results across thousands of records.

We also stabilised our machine learning workflow. Instead of retraining models dynamically during automated pipeline runs, we train our CatBoost models offline and package the resulting .cbm model files directly into the production container.

The pipeline loads three distinct models:

1. A classification model that calculates the probability that a course section receives bids.
2. A regression model predicting the median clearing bid price.
3. A regression model predicting the minimum successful bid price.

To give students actionable safety margins rather than just raw point estimates, the pipeline fits a Student's t-distribution on historical validation residuals. This generates empirical and theoretical safety factor multipliers per academic term, covering the 1st through 99th percentiles. A student can then choose their preferred risk tolerance when planning their bid amounts.

Unifying the Fragmented Student Ecosystem

With the data pipeline stabilised and writing into our shared PostgreSQL database, we focused on consolidating student utilities directly into AfterClass.

Over several months, we integrated the core functionality of two other open-source student tools:

1. smu-mods: We ported its timetable layout engine, including day-to-time-slot axis transposition and Singapore standard time academic calendar calculations (smu-acad-calendar.ts). We implemented custom iCal subscription feeds that correctly handle university recess weeks without shifting calendar event recurrence patterns.
2. SMU-BidWise: We brought over its interactive degree progress roadmap. During the port, we identified an architectural flaw in the original project: loading a single graduation plan triggered thirty-two sequential database queries to populate course requirements. We restructured the roadmap data model in Prisma, collapsing the thirty-two queries into a single optimised tRPC procedure.

During this consolidation, we modernised the entire technology stack, upgrading to Next.js 15, React 19, and Tailwind CSS v4.

Why We Built MCP and In-App AI

Bringing together reviews, bidding analytics, syllabi, class schedules, and degree roadmaps solved the data fragmentation problem.

However, it introduced a new cognitive challenge: information overload.

To plan a single semester, a student still had to open a course, inspect five semesters of bidding history, check reviews across three different professors, examine class meeting times for timetable clashes, and verify whether the module satisfied graduation prerequisites. Students were doing manual cross-referencing across different pages of our own website.

We realised that generative AI could serve as an effective research assistant for students, synthesising schedules and filtering course options.

However, running AI features presents a significant financial challenge for an open-source student platform. AfterClass has a soft policy against commercial display advertising. In our experience, banner ads generate negligible revenue while cluttering the interface and degrading the user experience. The platform is maintained purely out of passion for the student community. That meant every AI feature we built had to operate with near-zero marginal cost.

To solve this, we adopted the Model Context Protocol (MCP) and implemented a "One Catalog, Two Doors" architecture.

Instead of deploying a separate Node.js server on external infrastructure, we embedded our MCP server directly into our Next.js App Router at /api/mcp using mcp-use/next. By wrapping our Next.js configuration with withMcpUse(), the MCP endpoint and discovery routes at /.well-known are compiled directly into our Vercel serverless deployment.

We implemented fifty tools in a shared catalog. The exact same tools power both the website chat assistant and external AI clients.

To encourage students to adopt MCP in their own clients, we developed seven interactive MCP Apps views:

• course-search: Displays visual course summary cards directly inside the chat interface.

• calendar-links: Provides one-click subscription buttons for Google Calendar and iCal feeds.

• my-bid-plan: Visualises selected courses against the student's remaining bidding budget.

• get-my-roadmap: Renders an interactive degree plan matrix.

• get-course-reviews: Shows professor ratings, review distributions, and student feedback.

• explore-bid-options: Renders historical bid percentiles and clearing price charts.

• get-my-timetable-detail: Displays a formatted weekly schedule block.

By providing rich visual interfaces within native LLMs, students get the benefits of AfterClass without requiring us to absorb high AI inference bills.

Serving thousands of students on a low budget

With 23,158 registered student accounts and peak traffic surges during October course bidding, an unconstrained AI chat feature could quickly accumulate hundreds of dollars in API bills. We set a strict requirement: total operational AI spend must remain under twenty dollars per month.

To achieve this, we engineered multi-tiered safeguards:

1. Model Routing via OpenRouter

Instead of binding the application to high-cost proprietary APIs, we route requests through OpenRouter (@preset/afterclass). This gives us dynamic fallback capabilities and allows us to utilise high-throughput, cost-effective models. To absorb some of the cost, we utilised free models in Openrouter.

2. Preventing Streaming Race Conditions

In traditional chat applications, user quota is checked at the start of a request and decremented in an onEnd callback after the stream finishes. This creates a time-of-check to time-of-use (TOCTOU) vulnerability: a user can open five simultaneous tabs or cancel the stream mid-flight, obtaining unlimited responses without decrementing their balance.

We eliminated this in quota.ts by using atomic pre-reservations. Before any LLM generation starts, a database transaction checks and decrements the user's monthly allowance in a single query:

If the stream fails before generating any output tokens, a rollback function safely refunds the reserved message.

3. Canned Responses and Scope Denylists

A substantial portion of user inquiries consist of routine questions such as "What can you do?".

We implemented a canned response router that intercepts common queries before they reach the language model. These return static markdown responses instantly at zero token cost.

For query filtering, we initially experimented with an allowlist keyword classifier. However, it generated frequent false positives, rejecting valid queries like "What do people say about professor X?". We revised this to an off-topic denylist paired with a fail-open policy, filtering out irrelevant prompts while ensuring students receive answers to legitimate academic questions.

4. Secret Stripping and Context Trimming

When tools return calendar feeds or timetable records, the database results often include internal secrets such as private calendar feed tokens (icalToken) or share links.

Our centralised tool dispatcher sanitises all outputs before they enter the conversation context, removing private tokens and truncating tool payloads to a maximum of 24,000 characters. In addition, our context trimmer prunes older tool call histories, ensuring requests stay comfortably below our token limit.

The Evolution of My AI Agentic Workflow

Looking back across release 1.5.0, my engineering workflow changed as significantly as the platform itself.

When I started, I was prompting through the ChatGPT web interface. The models at the time regularly wrote bloated, procedural code with messy fallback logic, requiring hours of manual line-by-line cleanup.

As the project grew, I transitioned from casual web prompting to an orchestrator-led agentic workflow. Instead of writing boilerplate, my job became defining strict architectural specifications, clean DTO boundaries, and tool schemas. AI coding agents running in the terminal executed the implementation groundwork autonomously within those guardrails.

Moving to this spec-driven agentic flow is what allowed a single developer to rebuild an entire data pipeline, consolidate three open-source student tools, and ship an embedded fifty-tool MCP server in just six months.

Conclusion

Building software for university students is about focus and usability. Students do not need another experimental tool that will be abandoned when the founder finishes their degree. They need reliable, fast, and thoughtful tools that make academic planning easier.

By bringing together independent open-source efforts into AfterClass, we replaced a scattered ecosystem of one-off websites with a single, reliable hub. We eliminated brittle API dependencies in our data pipelines, embedded MCP tools without adding hosting costs, solved deep authentication conflicts, and provided AI assistance while staying within a twenty-dollar monthly budget.

If you are a student developer with an idea for a timetable feature, a data visualisation, or a planning utility, you do not need to start from scratch just to make an impact.

Join Us in Building AfterClass

We welcome contributions from designers, data enthusiasts, and engineers across the university. Whether you want to improve our bidding models, build new interactive MCP views, or refine the timetable engine, your work can directly help thousands of your peers every semester.