UTD Marketplace

The problem

Students buy and sell constantly: textbooks, monitors, dorm furniture at the end of every semester. 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

I collaborated in an Agile/Scrum team, managed Git version control, and participated in sprint reviews to prioritize features.

The interesting problem here was not the CRUD. It was state. A listing has a lifecycle, posted then pending then 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, like a confusing empty state or 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.