Project Info

TigerPop

Inspiration

TigerPop began from a common, frustrating campus problem: students constantly need textbooks, furniture, and event tickets, while others are looking to sell or give them away. However, the current solutions—scattered group chats and clunky social media groups—lack safe discovery, simple communication, and streamlined workflows. We set out to build more than just a classifieds page. We wanted a polished marketplace tailored specifically for campus life: fast, privacy-aware, and easy to operate for both students and administrators. Our goal was to create a modern product that lowers the friction of real-world transactions while keeping the community's trust intact.

What it does

TigerPop is a full-stack campus marketplace that enables verified communities to list, discover, and close sales with minimal friction. The platform manages the entire listing lifecycle—from creation and image management to status transitions (Available, Pending, Sold). Key features include: Dynamic Listing Lifecycle: Comprehensive CRUD operations for listings, allowing users to set categories, conditions, and prices. Smart Image Management: Multi-image uploads backed by Cloudinary with CDN-optimized delivery and server-side validation. Buyer Intent Capture: A "Request to Buy" system that records interest in the database and automatically moves listings to a "Pending" state to prevent double-selling. Dual Dashboards: Specialized views for sellers to manage active listings and for buyers to track purchased items and active requests. Admin Suite: Tools for moderation, category management, and CSV report exports for campus auditing.

How we built it

We adopted an API-first architecture, utilizing a TypeScript-based React frontend and a Flask (Python) backend. The Architecture Frontend: React + TypeScript with Tailwind CSS for a responsive, modern UI. Backend: Flask organized with modular Blueprints for Authentication, Listings, and User Profiles. Database: PostgreSQL managed via SQLAlchemy ORM. We used Alembic to track and manage schema migrations. Infrastructure: The project is designed for Vercel, utilizing serverless-friendly patterns. For instance, we dynamically adjust our database pooling based on the environment: Infrastructure: The project is designed for Vercel, utilizing serverless-friendly patterns. For instance, we dynamically adjust our database pooling based on the environment: Media: Cloudinary handles image storage and transformations, ensuring our server remains lightweight. Media: Cloudinary handles image storage and transformations, ensuring our server remains lightweight.

Challenges we ran into

Serverless DB Management: Ensuring short-lived serverless invocations didn't exhaust database connections was a hurdle. We solved this by implementing NullPool settings to ensure connections are closed immediately after a request. Upload Permutations: We spent significant time balancing the security of server-side image processing against the speed and convenience of client-signed Cloudinary uploads. UX vs. Moderation: Designing a flow that allows for "frictionless" posting while building in the hooks for future spam prevention and rate-limiting required careful state management.

Accomplishments we're proud of

Complete Lifecycle Flow: Successfully implementing a robust "Request-to-Buy" logic that reliably transitions database states. Clean Separation of Concerns: Building a distinct modular backend that is ready to be consumed by a future mobile app without requiring code changes. Production Readiness: Even at the MVP stage, we implemented Alembic migrations and environment-aware configurations, ensuring the app is ready for a real-world campus rollout.

What we learned

Deployment is a Feature: We learned that production-like considerations—such as database pooling, CDN usage, and CORS-safe configurations—are just as vital as the core business logic. Contract First Development: Investing early in the backend-frontend "contract" (API design) allowed our team to work in parallel without constant blockers. The Power of Serverless: Building with Vercel taught us how to design Python applications that are truly stateless and scalable.

What's next

Notifications: Integrating SendGrid or Resend to move beyond database "intent" to real-time email/SMS alerts for sellers. Identity Verification: Implementing campus NetID/CAS integration to ensure that only verified students can participate in the marketplace. Rate-Limiting: Adding middleware to protect critical endpoints (uploads and requests) from automated spam. AI Enrichment: Utilizing computer vision to provide condition estimates and price suggestions based on uploaded listing photos. Built With: Backend: Python, Flask, SQLAlchemy, Alembic, PostgreSQL, Cloudinary Frontend: React, TypeScript, Tailwind CSS, React-Router Deployment: Vercel, Python Serverless Functions

TigerPop — Princeton community marketplace

TigerPop is a full-stack marketplace web application built for the Princeton community. It lets students buy and sell items (furniture, clothing, textbooks and more), manage listings, favorite items, and communicate interest — all with secure authentication and image uploads.

This repository contains a React + TypeScript frontend (in frontend/) and a Flask backend API (in backend/). The frontend is deployed as a static site and the backend runs as Python serverless functions (configured for Vercel in vercel.json).

Notable features

User authentication with CAS integration and JWT session tokens.
Create, edit, search and filter listings with categories, price and condition.
Image upload support via Cloudinary (secure image hosting and CDN).
Listing “hearting” (favorites) and buyer/seller flows including email notifications.
Responsive modern UI built with React, TypeScript and Tailwind CSS.
RESTful API built with Flask, SQLAlchemy and PostgreSQL.

Technology stack

Frontend: React, TypeScript, Tailwind CSS, react-router.
Backend: Flask, SQLAlchemy, Flask-Migrate, Flask-JWT-Extended, Flask-Mail.
Database: PostgreSQL (production), SQLite for local dev.
Uploads: Cloudinary for image storage and delivery.
Auth: Princeton CAS integration + JWT for API auth.
Deployment: Vercel for frontend + serverless Python API; Heroku (historical) examples remain in config.

Quick start (development)

Prerequisites: Node.js (v18+ recommended), Python 3.10+, and a Postgres DB (or use SQLite locally).

Frontend

cd frontend
npm install
# start dev server
npm run dev

Backend (local)

# from repo root
python3 -m venv .venv
source .venv/bin/activate
pip install -r requirements.txt
export DATABASE_URL='sqlite:///local.db'   # or your Postgres DATABASE_URL
export JWT_SECRET_KEY='your-secret'
export SECRET_KEY='your-secret'
python backend/run.py

Visit http://localhost:3000 for the frontend and http://localhost:8000 (or configured port) for backend routes.

Analysis

Compare with all teams

View

Metric

No commits on this project resolved to a GitHub account.

Technology

Found in codeClaimed only

CSSIn code
FlaskIn code
HTMLIn code
JavaScriptIn code
PythonIn code
ReactIn code
SQLIn code
Tailwind CSSIn code
TypeScriptIn code
PostgreSQLClaimed
VercelClaimed

9 of 11 appear in the indexed code. 2 claimed on Devpost could not be matched to code, which may simply mean the tool leaves no trace in the repository.

AI coding agents

No AI coding agent signals were found in this repository.

Detected from committed agent config files and commit authorship. Absence of a signal is not proof an agent was unused.

Codebase size

Source size

181 KB

Source files

Counts recognized source files only; vendored directories, binaries and lockfiles are excluded, so this is smaller than the repository on disk.

Repository

angelztang/treehacks26

129 files · 8.3 MB · @ a5b4815

Structure

Interface
29 files · 22%
Screens, components and styles rendered to the user.
API & routing
6 files · 5%
Request entry points: routes, handlers and controllers.
Application logic
43 files · 33%
Domain rules, services and shared utilities.
+1 more
Data & schema
14 files · 11%
Schema definitions, migrations and data access.

Supporting

Layers are inferred from where files sit in the tree, not from reading the code. A project that names its directories unconventionally will read oddly here — open the file browser to check anything the diagram implies.

Languages

TypeScript53%
Python41%
Markdown4%
JavaScript1%
Shell0%
SQL0%
Other (2)0%

Share of indexed source by file size. Binary and vendored files are excluded.

Dependencies

frontend/package.json

npm · 20

@heroicons/react
@testing-library/jest-dom
@testing-library/react
@testing-library/user-event
@types/jest
@types/react
@types/react-dom
autoprefixer
axios
postcss
react
react-dom
react-router-dom
react-scripts
serve
tailwindcss
typescript
web-vitals
+2 more

backend/requirements.txt

pypi · 15

bcrypt
cloudinary
Flask
flask-cors
Flask-JWT-Extended
Flask-Mail
Flask-Migrate
Flask-SQLAlchemy
gunicorn
Pillow
psycopg2-binary
python-dotenv
requests
SQLAlchemy
Werkzeug

api/requirements.txt

pypi · 14

bcrypt
cloudinary
Flask
flask-cors
Flask-JWT-Extended
Flask-Mail
Flask-Migrate
Flask-SQLAlchemy
Pillow
psycopg2-binary
python-dotenv
requests
SQLAlchemy
Werkzeug

package.json

npm · 14

@testing-library/jest-dom
@testing-library/react
@testing-library/user-event
@types/jest
@types/node
@types/react
@types/react-dom
axios
react
react-dom
react-router-dom
react-scripts
typescript
web-vitals

requirements.txt