The problem
A campus marketplace needs more than listings. Users need to understand who is selling, recover access to their accounts, upload photographs, contact sellers safely, and manage their own listings without exposing credentials or giving other users control over their content.
From team project to portfolio system
The original application was a four-person York University course project. My original contributions included registration and recovery email notifications, password recovery, York email OTP verification, item search and live suggestions, and listing and homepage workflow fixes.
I later maintained an independent portfolio edition, adding production-oriented infrastructure, security improvements, cloud media storage, verification tiers, protected reviewer access, automated testing, database migrations, CI/CD, and deployment work. The original team repository and contributor credit remain distinct from these later improvements.
Marketplace journey
Visitors can browse public listings without signing in. Sellers can register, verify their email address, create listings, upload photographs, and manage only the items they own.
York email verification adds a York Verified Student badge, while other verified sellers remain clearly distinguished from York-verified accounts.
Reviewers can use a protected read-only demo path, and buyers can contact sellers through controlled email inquiries. Payments and physical exchanges take place outside the application.
Architecture
- Java 17 + Spring Boot + Thymeleaf: Server-rendered marketplace pages and application workflows.
- Spring Security: Session authentication, protected routes, BCrypt password hashing, OTP verification, password recovery, ownership authorization, and reviewer restrictions.
- PostgreSQL + Spring Data JPA + Flyway: Persistent accounts, listings, verification state, and versioned database migrations.
- Cloudflare R2 + AWS SDK: Private object storage for listing photographs with application-controlled access.
- Docker + Render: Containerized deployment in a reproducible runtime environment.
- GitHub Actions: Automated Maven build and test validation on pushes and pull requests.
From course project to durable application
Moving beyond local development meant addressing the less visible parts of a usable application: persistent data and images, expiring verification and recovery credentials, owner-only mutations, protected reviewer access, repeatable database migrations, automated tests, and deployment.
The verification model also needed precise language. A verified public seller is not automatically a York student; the York Verified Student badge specifically represents verified institutional email ownership.
Result and scope
The portfolio edition is a deployed marketplace with public browsing, persistent listings and photographs, account recovery, verification tiers, ownership controls, and a protected read-only reviewer path.
The repository includes automated coverage for authentication, ownership, recovery, and media behaviour.
YU Bazaar remains a portfolio MVP. Payments, escrow, delivery, and real-time chat are outside its scope, and the hosted application may take a moment to wake after inactivity.
What the project taught me
The biggest lesson was that production readiness often lives in the less visible paths: authentication, account recovery, persistence, ownership rules, media storage, database migrations, deployment, and test coverage.
Modernizing an existing team project also reinforced the importance of preserving attribution while evolving the architecture independently.