CS50W project

Commerce

An eBay-style auction platform with listings, bidding, watchlists, comments, and category browsing.

Python
Django
HTML
CSS
SQLite
Django ORM

Commerce auction application marketplace preview — auction marketplace preview

BUILT WITH CS50W

Built with CS50W.

Commerce is a course project from CS50's Web Programming with Python and JavaScript - Django, from database schema to server-rendered pages.

CS50W course project

THE IDEA

An auction house, built one model at a time.

Commerce is an eBay-like auction web application. Users create listings, place bids, leave comments, keep a personal watchlist, and browse listings by category - built for CS50's Web Programming with Python and JavaScript (CS50W).

The focus was the backend: designing a relational schema in Django, wiring up user authentication, validating every form on the server, and getting the auction business logic exactly right.

HOW AN AUCTION WORKS

From listing to hammer-down.

The five moves behind every auction on the site.

Create listing
Users place bids
Bid validation
Auction closes
Winning bidder

Every bid is checked.

A bid only earns its place if it clears the current price - the highest bid so far, or the starting bid when the auction is fresh.

Must be a valid amount
Must beat the current price
Becomes the new highest bid
Updates the current price

WHAT I BUILT

The core features.

Eight compact areas cover the whole app - no production features promised yet.

Authentication

Register, log in, and log out
A signed-in identity drives the whole app

Auction listings

Create listings with title, description, and starting bid
Optional image URL
Every listing picks a category

core logic03

Bidding

Place bids with validation enforced
The current price is the highest bid
Every bid is recorded and owned by a user

Watchlist

Add and remove listings in one click
Backed by a many-to-many relationship

Comments

Leave comments on any listing
Authors can delete their own comments

Auction closing

Owners close their own auctions
The highest bidder is the winner

Admin control

Django admin manages listings, bids, and comments

THE FEATURES IN DETAIL

Six systems, one marketplace.

The flow behind the features, from accounts to admin.

AUTHENTICATION

One identity for everything.

Django's built-in user system drives registration, login, and logout. Bidding, watchlisting, and commenting all tie back to the signed-in user.

AUCTION LISTINGS

Set a starting bid, open the floor.

Anyone can publish a listing with a title, description, starting bid, optional image URL, and a category. Active listings flow straight onto the homepage.

WATCHLIST

Save it for later.

A personal watchlist per user via Django's many-to-many field. One click adds, one click removes, and a dedicated page lists everything saved.

COMMENTS

Say something useful.

Signed-in users can leave comments on any listing and delete their own. Every comment is stored with its listing and its author.

Shop a shelf, not the whole store.

Every listing belongs to a category. Browse the category index, then open one to see its active listings only.

ADMIN

Manage it from the admin.

Django's admin interface handles listings, bids, and comments out of the box - no custom dashboard needed.

ListingsBidsComments

The Django admin is the cockpit: listings, bids, and comments, managed without touching the app's own code.

BIDDING LOGIC

Bids that have to earn their place.

Placing a bid is where Commerce does its real work. Every bid is checked before it ever touches the database.

A bid must be a valid numeric amount
It must beat the current price - the highest bid so far, or the starting bid when there are none
If it fails, it's rejected with a clear message
If it passes, it's saved and becomes the new highest bid

CLOSING THE AUCTION

When the hammer comes down.

Only a listing's owner can close it. Once closed, the auction is over and the highest bidder takes the win.

OpenBiddingClosedWinner

hammer down - highest bid wins

UNDER THE HOOD

How it's built.

A server-rendered Django app on SQLite, styled with plain HTML and CSS.

Backend

PythonDjango

Frontend

HTMLCSS

Database

SQLite

Data layer

Django ORM

THE DATA MODEL

Five models, one centre: the listing.

Users, listings, bids, comments, and categories - with listings at the centre of almost every relationship.

UserListingsBids

Bids hang off a listing and remember who placed them.

UserWatchlistListings

A many-to-many watchlist links users to saved listings.

ListingComments

Comments belong to a listing, each with an author.

ListingCategory

Every listing is filed under one category.

RELATIONAL DATA

Relational by design.

ListingsBidsCommentsCategoriesWatchlists

Everything sits on Django's ORM. The current price is derived from the related bid records, the watchlist is a through-table in the background, and per-user pages are just filtered queries.

FORMS THAT DO THE WORK

Django forms, server-side.

New listing formBid amount checksComment postingValidation before save

Every form - new listing, bid, comment - is validated server-side before anything is saved. A ModelForm turns clean user input into a real listing.

WHAT I WAS LEARNING

Coursework, put to work.

Each objective from the project brief, matched by what got built.

Django modelsDefining users, listings, bids, comments, and categories as real data.
Database relationshipsForeign keys and many-to-many links between the models.
User authenticationDjango's built-in users, with registration, login, and logout.
AuthorizationDeciding what a signed-in user can and cannot do.
Django formsModelForms that turn requests into validated, typed data.
Server-side validationChecking input on the server before it ever hits the database.
The Django ORMQuerying relational data without writing raw SQL.
Bidding business logicThe rules that keep every auction fair.
Dynamic pagesPages that change with the logged-in user and auction state.