Production Notes
OSAP GLITCH
“Behind the Scenes”
2026
Synopsis
OSAP GLITCH matches students with scholarships they actually qualify for. It takes the overwhelming process of searching for financial aid and simplifies it by intelligently pairing student profiles with relevant opportunities.
The Problem
Finding scholarships as a student is exhausting. You end up scrolling through hundreds of listings, most of which you don't even qualify for. There's no central place that filters by your actual profile, so students either miss deadlines or give up entirely. We wanted to fix that.
Starring
Production Challenges
Scholarship Data Aggregation
Pulling together scholarship data from multiple sources with wildly inconsistent formats was a real data engineering headache. We ended up building robust scraping and cleaning pipelines to normalize everything.
Rate Limiting at Scale
Setting up SlowAPI for rate limiting while keeping things smooth for users was a balancing act. We had to carefully tune request quotas and give useful feedback when someone hit the limit.
Matching Algorithm
Building an accurate matching engine that weighs eligibility criteria, deadlines, and student profiles took a lot of iteration. We kept refining it to cut down on irrelevant results.
Production Design
The frontend is a vanilla JavaScript and CSS single-page application served from AWS, with Figma-designed UI components. We deliberately chose vanilla JS over a framework like React because the app is mostly static forms and result lists, and skipping a framework kept the bundle tiny and the deploy pipeline dead simple for a student-facing tool where speed matters more than interactivity. The backend runs on Python FastAPI with SlowAPI middleware for token-bucket rate limiting, keeping endpoints protected from abuse while maintaining response times under 200ms. We evaluated Flask and Django before landing on FastAPI; Flask lacked async support out of the box, and Django was too heavy for what is essentially a matching API. FastAPI gave us async handlers, automatic OpenAPI docs, and Pydantic validation with minimal boilerplate. MongoDB stores student profiles and a normalized scholarship database aggregated from multiple sources with inconsistent formats. We chose MongoDB over PostgreSQL because scholarship data varies wildly in shape across sources, and a flexible document model let us iterate on the schema without painful migrations during the early data aggregation phase. We cleaned all of that through custom ETL scripts that standardize eligibility criteria, deadlines, and award amounts. The matching engine queries MongoDB with compound indexes on eligibility fields, scoring each scholarship against the student's profile (GPA, program, demographics, financial need) using a weighted multi-criteria algorithm. We considered vector-based semantic matching but decided the eligibility criteria are structured enough that weighted scoring gives more transparent and debuggable results, which matters when students need to trust the recommendations. API responses are paginated and cached to reduce database load under concurrent user sessions.