Dorms @ Brown

The information existed. It was just scattered across a university housing page, a few years of forum posts, and whoever you happened to know who had lived somewhere. There was no single place to see what a room actually looks like or hear what the people in it thought.

The cost landed on students as a bad decision they lived with for a year, and on Residential Life as a steady stream of one-off questions that better upfront information would have answered.

The frontend never talks to the database. Every read and write goes through a Java server, which is the only thing holding admin credentials; the client holds a public config good for sign-in and photo upload and nothing else.

That split is what forced the deployment shape. GitHub Pages serves static files only, so the server needed a real host and runs as a container elsewhere, with the service-account key passed in as an environment variable rather than a file, because most container platforms have no friendly way to drop in a raw secret.

Dorm photos are phone snapshots in every orientation and resolution. Hard-cropping a tall photo into a fixed frame cuts off half the room, which is the half you wanted.

The gallery letterboxes the full photo over a blurred, darkened copy of itself filling the rest of the frame. Nothing is cropped, the frame stays a consistent size, and the fill reads as intentional rather than as empty space.

I had thought of hosting as something that happens after the build. It is not: the static-host constraint decided the architecture, the auth flow and the routing, and every one of those is visible to the person using it.

Client-side routing on a project path needed an explicit basename and the redirect trick for deep links, because there is no server to rewrite a URL. That is a design decision that arrived from the infrastructure, and I would now go looking for those earlier.