Apps & tools I've built.

Healthcare workers in rural Senegal often reach patients long before a physician does. The goal was a tool that supports the reasoning a clinician would do — not one that hands down an answer and asks to be trusted.

The system runs a ReAct-style loop — thought, action, observation — over three specialist agents. One conducts the patient interview and asks for what's missing, one retrieves supporting medical knowledge, and one synthesizes a ranked differential. A driver advances the whole thing through a five-state machine, and the interface exposes that machine rather than hiding it: you watch each agent activate, and symptoms accumulate as they're extracted from the conversation.

It was built over a full semester on a sprint cadence with versioned releases, for an external sponsor and alongside collaborators at Pitt. A communication logger written into the system captures every exchange between agents — which is what makes the consultations on this page replayable at all.

A restaurant ordering system built around the awkward part of the problem: the front of house and the kitchen are looking at two different screens, and they have to stay in agreement without anyone shouting.

Each table carries its own QR code, so scanning it opens a menu already scoped to that table — no table number to mistype, no waiting to be handed a tablet. Orders post through REST endpoints to a Flask and SQLAlchemy backend, and the kitchen view picks them up and tracks them through preparation, with the DOM updated in place rather than reloaded.

The interesting constraints were the unglamorous ones: keeping order state consistent when two clients act at once, and building a responsive layout that works on a phone held over a table and on a fixed kitchen display.

Every convenience you'd normally reach for is gone here. No libraries, no graphics engine, no data structures — just registers, memory, and a framebuffer mapped straight into the address space.

Drawing a pixel means computing its offset by hand. The straight-line tool is Bresenham's algorithm implemented in branches and shifts. The flood fill is genuinely recursive, which on a machine where you manage your own stack means the interesting failure mode is running out of it — bounds checking isn't defensive programming here, it's the difference between a fill and a crash.

The recording keeps the full MARS window in frame on purpose: registers and source visible behind the display, so it's clear this is really assembly and not a simulation of one.

The same bare machine as the paint program, pointed at a different problem: how 2D game levels actually get authored.

The grid is a tile index in memory, and drawing it means walking that array and blitting each tile's pixel block to the right framebuffer offset — the same indirection a real tile engine uses, just written out by hand. A cursor moves on keyboard input, and each tile type is a palette entry the cursor stamps down.

Separating what the map is (the index in memory) from how it's drawn (the blit loop) is the whole lesson of the assignment, and it's the same separation that survives all the way up into engines built in real languages.