UTD Marketplace

The problem

Students buy and sell constantly — textbooks, monitors, dorm furniture at the end of every semester — and the alternatives are all bad. Public marketplaces mean meeting strangers off campus. Group chats mean a listing scrolls away in an hour.

What I built

I worked on the interface and the authentication layer of a marketplace scoped to UT Dallas students.

Authentication runs on Firebase Auth, which keeps the marketplace closed to the campus community. That constraint is the product: a buyer knows the seller is another student, and a meetup can happen somewhere on campus in daylight.

Real-time listings use Firebase's subscription model rather than polling. A new post appears in every open browser as it is written, so two students never negotiate over an item that sold ten minutes ago.

Engineering notes

The interesting problem here was not the CRUD. It was state: a listing has a lifecycle — posted, pending, sold — and several people can act on it at the same time. Driving the UI off the live database rather than a local copy meant the interface could not drift out of sync with reality, which is the failure mode that makes a marketplace untrustworthy.

The project reached more than 1,500 students, which changed how I think about writing code. Things that are invisible at ten users — a confusing empty state, an unhandled auth error — turn into a steady stream of people who cannot use your software.

What I would change next

I would define the listing lifecycle as an explicit state machine and move competing updates behind transactional writes. I would also add lightweight moderation and clearer ownership analytics so the team could distinguish registered accounts, active users, and the wider student audience reached by the launch.