Toronto
| S | M | T | W | T | F | S |
|---|
Press Enter or double-click to open.
Nothing here yet. Go open something.
4 items
2 October 2026 at 11:24
about me
Hey, I’m Usha!
I’m Cambodian and Indian. I grew up in five countries across three continents. That's taught me a couple of things: how to start over, adapt, and how to lose an hour scrolling around Google Maps.
I came to UofT for Politics and Economics and switched to Computer Science in my third year. It’s why I like problems where the technical answer also has to make sense to real people.
I’m now finishing a CS Specialist and Math minor, graduating Summer 2027. At the University of Helsinki, I took graduate-level computer vision and AI and wrote a paper on contraction hierarchies, the trick behind fast route-finding. These days I build at the intersection of AI and full-stack engineering.
right now
I’m looking for full-time SWE, ML and product roles starting in 2027. If you're interested, or you just want to say hi, Mail is on the dock :)
28 September 2026 at 05:10
currently
- reading: the silent patient
- learning: better time management
- finishing my last year at UofT!
- getting into graph neural networks
- enjoying some fall activities!
14 September 2026 at 17:45
things I love
scrolling on Google Maps
Pinterest moodboards
cooking for friends:)
5 October 2026 at 08:00
about this site
This is my portfolio, built to feel like my laptop. Everything opens like an app.
what’s here
- Finder: my projects, with write-ups, screenshots and links
- Maps: my experience, as a route through the places I’ve lived and worked
- Notes: a bit about me (you’re in it)
- Terminal: poke around the whole site by typing (try help)
- Mail: send me a message
quick links
Message sent
Thanks for writing! I’ll get back to you soon.
{name}@portfolio
Hardware
- CPU
- one brain, 2 tabs open (mostly)
- GPU
- integrated imagination
- RAM
- remembers bugs, forgets names
- CAFFEINE
- dangerously adequate
- STORAGE
- side projects
- SLEEP
- final-year mode
Session
- USER
- unknown
- BROWSER
- unknown
- OS
- unknown
- SCREEN
- unknown
- CORES
- unknown
- TIMEZONE
- unknown
- LOGIN
- unknown
Trash
Coming soon!
3 items
SpendWise
what it is
Ontario cut OSAP’s non-repayable grants from up to 85% of funding to 25% at most, so more of what students get now has to be paid back. Meanwhile, the scholarships that could fill the gap are scattered, outdated and hard to decode, deadlines get tracked by hand, and qualified students miss money they’re eligible for. Students need smarter tools, not more spreadsheets.
SpendWise brings it into one place for UofT students:
- Financial tracking: a dashboard for tuition, OSAP, scholarships and expenses, with bank accounts connected through Plaid
- Scholarships: every UofT scholarship, matched to your profile and tracked through to submission (the part I built)
- Saving money: verified student discounts, spending analysis and a practice investing tool
It shipped as a containerised app on DigitalOcean, with CI that blocks any pull request dropping below 80% test coverage.
my role
Product Manager & Full-Stack Engineer on a 7-person team, Jan–Apr 2026 (UofT CSC301). I pitched the idea, ran the project, and built the scholarships feature from scratch, plus the profile system and site-wide theming.
stack
React and Vite on the frontend; Django and Django REST Framework with PostgreSQL on the backend; a Python scraper (requests and BeautifulSoup); Docker Compose, Nginx and GitHub Actions for deployment. Jira for planning, Figma for design.
what I built
Running the team. I set up our Jira board, led sprint planning and the roadmap, and did the early Figma prototypes. With seven people working across the UI, backend and data, I used 1-on-1 check-ins to find and unblock stuck work before it held anyone else up.
Scholarship data. A scraper for UofT’s Award Explorer that parses every listing and normalises amounts, deadlines and eligibility into structured records: about 4,300 undergraduate scholarships, plus graduate awards. Ingestion is idempotent: upsert logic and a last-seen timestamp mean re-running it updates existing records instead of duplicating them.
Finding the right ones. A REST API with search, filters and pagination, and a match endpoint that ranks scholarships against a student’s profile (faculty, major, year, degree type and citizenship) and says why each one matched.
Actually applying. Students can bookmark scholarships and move them through Saved → In Progress → Submitted on a drag-and-drop board, with colour-coded status pills and every move synced to the backend. A reusable Upcoming Deadlines widget appears on both the Dashboard and the Scholarships page, so deadlines stop living in people’s heads.
Accounts and theming. The profile system: a dedicated edit page, a navbar dropdown with user info, a /api/me/ endpoint, and token refresh so sessions stay consistent. I also built dark and light mode from the ground up, with a theme context, a saved preference, and dark overrides across every page and component.
Polish. A time-of-day dashboard greeting, consistent fonts and buttons, high-contrast dropdowns, and a settings menu with a bug-report form.
the hard part
We almost didn’t have a project. Our original partner placement fell through, and we lost close to a month of a four-month course. We pitched SpendWise as a replacement, and our first deliverable got tough feedback from the TAs on both scope and execution. From then on, every presentation was also a re-pitch: we had to prove the project could ship. As PM, that meant cutting scope hard, focusing each deliverable on an MVP we could demo, and pushing everything else to “next steps”.
On the technical side, the data was the hard part. Award Explorer wasn’t built to be scraped: eligibility lives in free text, and amounts and deadlines come in inconsistent formats. Getting re-runs to update records cleanly instead of piling up duplicates is what pushed me toward the upsert design.
what I’d do next
I’d use an LLM to turn free-text eligibility into structured criteria, which would make matching far more accurate than rules on a handful of profile fields. I’d also run the scraper on a schedule instead of by hand each term, and send email reminders before saved scholarships’ deadlines.
8 items
Socrato
what it is
Most students use AI to skip the work that actually makes things stick: paste notes, read a summary, feel like you studied. Socrato flips that. The AI generates the material, and you do the remembering. Paste your notes once and get a summary, a quiz and a flashcard deck, with a game layer that keeps you coming back.
Built by a team of four through GDG UTM’s Community Projects Initiative (CSC392/492), alongside a research paper on designing against passive AI use.
my role
Software Developer, Jan–Apr 2026. I owned the flashcard feature end to end, from research to generation to review and scheduling, and built the Gemini API calls behind the summaries and quizzes.
stack
Next.js, TypeScript and React on the frontend; a Python FastAPI backend; Gemini 2.5 Flash for generation; Supabase for auth and PostgreSQL storage.
what I built
Flashcards, designed from the research up. Before building anything, our team dug into what actually makes studying work. Two findings shaped my feature: actively recalling information beats rereading by a wide margin (in one study, students who practised retrieval forgot about 13% of material after two days, versus 56% for those who restudied), and spreading reviews out over time beats cramming. Flashcards with spaced repetition are one of the few tools that do both at once.
So Socrato generates ten flashcards straight from your notes, with a question on the front and the answer on the back. You flip each card and rate how well you knew it: Again, Hard, Good or Easy. Those ratings feed the SM-2 algorithm, which schedules each card to come back right around when you’re about to forget it: sooner for the ones you struggled with, later for the ones you knew. Decks save to your profile for later sessions.
Generating the cards automatically mattered as much as the algorithm. Making flashcards by hand takes long enough that most students never do it consistently, and research on tools like Anki suggests that cards matching your actual course content are a big part of why they work. Building them from your own notes removes that friction.
The generation pipeline. I built the FastAPI endpoints that call Gemini to produce the summaries, quizzes and flashcards. Each one sends a carefully engineered prompt and expects a strictly specified JSON structure back, which Pydantic validates before anything reaches the UI.
Keeping ratings honest. Spaced repetition only works if students rate themselves truthfully, and that tied directly into our XP system. Flashcard XP is earned per session (once a day), not per card marked “Easy”, so inflating your ratings earns you nothing; it just makes your reviews worse. The points that do depend on performance come from quizzes, where XP is only awarded for correct answers.
the hard part
Getting an LLM to produce flashcards worth studying. Early outputs were inconsistent: cards that were too vague, too long, or just restated the notes, and responses whose structure changed from one call to the next, which broke the UI. I did a lot of reading on prompt engineering and rebuilt the prompts around an explicit JSON specification (exactly which fields, what each should contain, how long), then validated every response against Pydantic schemas so a bad generation fails cleanly instead of rendering nonsense.
Scheduling had its own catch: SM-2 has nothing to go on until you’ve rated cards at least once. My first version simply showed a new deck in random order, letting the first session’s ratings give the algorithm its starting signal.
what I’d do next
Find out whether it actually works. Our design is grounded in learning science, but we never tested it, so I’d run a small study comparing students who use Socrato with students using a generic AI tool on the same material. I’d also improve the cold start, for example by using quiz results to seed which flashcards come first, since the quiz already tags each question with a topic. And I’d add per-topic mastery so students can see which concepts they’re weakest on.
2 items
Portfolio Optimizer
what it is
A portfolio optimizer: pick a universe of stocks and it finds the mix with the best risk-adjusted return under a volatility limit, then shows how that portfolio would have done against the S&P 500.
my role
Personal project, Dec 2025.
stack
Python (FastAPI, cvxpy, pandas), React, REST API.
what I built
The FastAPI backend screens a user-defined stock universe and solves a mean-variance convex optimization with cvxpy to maximize risk-adjusted returns under volatility constraints.
The React frontend talks to it live, visualizing the optimal asset weights, the efficient frontier, the sector allocation breakdown, and a backtest of the portfolio against the S&P 500 over a date range you choose.
More info coming soon!
the hard part
what I’d do next
6 items
ourPATHS
what it is
Before a new drug is covered in Canada, bodies like CDA and pCPA publish decisions on whether to reimburse it, under what conditions, and after how long. That history is gold for pharmaceutical market access teams, but it’s locked in unstructured PDFs, every source uses its own format and terminology, and there’s no shared database. Teams search and extract it by hand.
ourPATHS (Observational, Usable & real-Time Predictive Analytics Toolkit for Healthcare Strategy) pulls it all into one place: a dashboard for tracking drug submissions and trends, and a chatbot that answers questions like “what is Dupixent indicated for?” using the actual decision documents as its sources.
my role
LLM Engineer on a 5-person software team, working alongside a business team, May–Sep 2025 (UofT research project). We worked directly with stakeholders at three pharmaceutical companies. I designed the entire product in Figma, built the RAG chatbot end to end, and helped build the document pipeline behind it.
stack
Python and FastAPI on the backend; OpenAI for embeddings and answers; a fine-tuned Cohere model for intent classification; Azure Blob Storage and a vector database; Selenium, SQLite and SQLAlchemy for the data pipeline; React and TypeScript on the frontend, designed in Figma. Heavy processing ran on the Niagara supercomputer.
what I built
The design. I designed the whole product in Figma, from the dashboard (drug tracking, market news, therapeutic-area trends, portfolio predictions) to the chatbot interface. The prototype was how we scoped features with the team and walked pharmaceutical stakeholders through the product before it was built.
The chatbot, end to end. Every question first goes through a fine-tuned Cohere classifier that decides what kind of question it is: a lookup in the documents, a price recommendation, or a timeline prediction. Document questions go to the retrievers, which pull the three most relevant chunks from the vector database, and GPT-4-mini reads them and writes the answer.
Answers you can check. Market access teams can’t act on a confident-sounding guess, so every answer comes back in the same structure: the answer itself, key details, any caveats or assumptions, and the exact source PDF it came from.
The document pipeline. I helped build the pipeline that feeds it. It scrapes each source’s listings, downloads every decision PDF, and stores the basic fields (drug, dates, decision) in SQLite. Each PDF is then split into chunks, tagged with metadata like the drug and source, and embedded. Across 800+ HTA documents that came to 10K+ embeddings, stored in Azure Blob and a vector database for fast semantic search.
the hard part
Cost. We burned through ~$200 in API credits in our first three days. Processing hundreds of long PDFs and answering questions with a large model adds up fast, and our first setup was far more expensive than it needed to be.
That forced us to treat cost as a design constraint, not an afterthought. We moved answer generation to GPT-4-mini, which turned out to be plenty for reading three retrieved chunks and writing a structured answer, and switched to a much more efficient approach to embedding the documents. It’s also part of why retrieval only passes the top three chunks to the model: a tighter context is cheaper as well as more accurate. It was an early lesson that an AI feature isn’t finished when it works; it’s finished when it works at a cost someone can actually pay for.
what I’d do next
Two things I really wanted to build. The first is real-time market access data: instead of a snapshot of past decisions, the platform would pick up new decisions and updates as agencies publish them, so teams always see the current picture.
The second is private data upload, letting companies add their own internal drug information so the chatbot can answer questions about their pipeline, not just public decisions. What interests me most is the security side: how to keep one company’s documents completely isolated from another’s in the same system, control exactly who can access what, and guarantee that sensitive data never leaks into shared indexes or another user’s answers. For data this commercially sensitive, that’s what makes or breaks whether anyone would trust the tool.