OPEN THE HOOD
Small details.
Real decisions.
The screen is one part of the work. Here are the connections, checks and tradeoffs behind it.
Team software, integration work, maps and a game that became its own small world. Pick a thread; there’s more at the other end.
TEAM SOFTWARE · GDSC · WINTER 2022
Follow the request.
Our six-person University of Toronto team built the GDSC application portal. My sprint assignments included login, the registration connection, bug reporting and superuser login. Those are useful places to see how a user action crosses a stack.
- React interfaceA visitor supplies the registration fields or a bug report.
- Express routeThe team’s registration route checks for an existing email, then creates the user record.
- MongoDB modelThe route saves through a model and returns a response to the interface.
The repository also has routes for reporting, editing and resolving bugs. That gives the feature a lifecycle beyond its first form.
What I would test before using it today
Duplicate registration, missing fields, authorization on report changes, and whether each branch actually completes its HTTP response. I would also review password handling and error responses before any relaunch. An old course repository is useful evidence of the work; it is not a present-day security guarantee.
The route descriptions refer to the team’s implementation. The sprint records identify my assignments; they do not make me the author of every layer.
TEAM SOFTWARE · TRUSTAI · 2026
An answer is not the same as a useful answer.
As Product Owner and AI Analysis Lead, I worked on requirements, model comparison and output validation. The useful question was what the application could safely do with a model’s response.
Compare like with like
Controlled inputs make differences between model outputs easier to discuss. A fluent answer still needs to meet the task.
Check the contract
Structured outputs give the application something it can validate. The team’s provider interface separated model choice from the surrounding product.
Show the limits
Evaluation evidence has to explain the design choices as well as the result. A useful demonstration is not a large user study.
What I can walk through in a conversation
The comparison criteria, checks on structured output, and how model limitations affect a product decision. The team application used React, FastAPI and PostgreSQL; my role does not imply I implemented every service or trained a foundation model.
EMPLOYMENT · BUSINESS ANALYST · VIGILANT
The records have to agree.
My integration work connected Azure and Oracle financial-planning systems with Python, SQL, Azure Functions and APIs. Investigating inconsistent records and application errors was part of the work, alongside the transfers themselves.
A useful way into the story is to trace a record: where it began, what transformed it and where the destination stopped matching the expectation. That keeps a technical discussion grounded in the data rather than a list of cloud logos.
A technical conversation, without client data
I can discuss the transfer workflow, troubleshooting and validation approach at a general level. Client records, credentials and internal implementation details do not belong in a public case study.
GIS · COMMUNITY GARDEN + EARLIER SUPPORT WORK
A map is an argument you can inspect.
The Community Garden site analysis brought open spatial data, maps and written findings together in a team project. The aim was to make potential sites easier to compare, with the reasoning visible beside the geography.
That sits alongside earlier work compiling spatial data and environmental site-assessment material at Terraprobe, and GIS data preparation, digital mapping and ArcGIS Pro tutorials at the University of Toronto.
What the map can—and cannot—say
A site comparison depends on the inputs and criteria. I would explain those before treating the output as a recommendation. The project is not evidence that the city adopted a site or that a measured community outcome followed.
PERSONAL PROJECT · DEV RUN
Keep the simulation out of the scenery.
Dev Run separates its simulation from rendering, with authored routes and a character system around it. Movement, transit, weather and fullscreen have to fit together without turning every interaction into a new special case.
State and motion
The simulation owns the game state. The renderer turns that state into a scene.
Checks that matter
Route completion, movement constraints and fullscreen transitions are different checks. A screenshot cannot prove all three.
Room to explore
The untimed route keeps exploration available without a score becoming the whole point.
Optional accounts now support Google, GitHub and LinkedIn sign-in, saved member state and protected résumé access. Owner controls remain server-authorized and protected by passkey verification. The public portfolio stays open to everyone.
Implementation notes Play Dev RunTHERE IS MORE IN THE DRAWER
Earlier work still has a place.
Web work
Interfaces, routing, authentication flows, hosting support and functionality checks. A website still needs attention after the first page looks right.
Web development and QAOthello
A Java coursework archive, with supplied-code and individual-contribution boundaries kept visible.
Read the archive noteThe original portfolio
The earlier site remains part of the story, alongside the newer work.
Take a look backRouteAbility remains in the main project collection with its historical context. Explore all selected work
HAVE A ROLE IN MIND?
Let’s talk software.
Send the role, the team or the problem you’re working on. I’m interested in full-stack software roles and selected development projects across North America.
TRY A SMALL EXAMPLE
Where should this request stop?
A useful system has a good answer for the unhappy path. The decision desk makes three of those boundaries visible, with deliberately fictional records.
Open the decision desk ↗A small local illustration, not a client system or a live authentication service.