Acadex

Challenge

A marketplace becomes significantly more complicated once users need to interact with each other rather than simply browse static listings.

Acadex needed to support the complete lifecycle around a listing: creation, discovery, filtering, communication between buyer and seller, transaction state, reviews, reports, and moderation.

Because many of these systems operate on user-generated data, access control was also important. A user should not be able to read or modify private conversations, transactions, or administrative information simply by manipulating a frontend request.

Constraints

The application was developed within a university project timeline by a small team, so features had to be prioritised carefully.

We needed to demonstrate both engineering depth and a coherent finished product while avoiding an architecture that was unnecessarily difficult to maintain.

Supabase was used extensively, which made correct database modelling and Row Level Security policies important. Realtime functionality also needed to coexist with standard application state without creating inconsistent messaging behaviour.

Research

We examined common marketplace patterns around listings, search, messaging, seller reputation, reporting, transaction state, and moderation.

From there, we translated those patterns into a university-specific context rather than cloning a general marketplace.

We also spent significant time planning the database and relationships between users, listings, conversations, messages, transactions, reports, ratings, and reviews because mistakes at this layer would affect almost every feature above it.

Iterations

Acadex grew incrementally from its marketplace core into a larger system.

Listings and filtering established the initial product loop. Realtime messaging then introduced private communication between buyers and sellers.

Transaction state, reviews, ratings, reporting, and moderation added trust and accountability around those interactions.

Administrative tooling was developed to review reports and manage problematic content. Additional experimentation included Stripe payment flows, recommendation features, and AI-assisted search.

Testing expanded alongside the application, eventually reaching 39 test files with 187 passing tests.

Key Features

• Student marketplace listings
• Listing creation and management
• Search and filtering
• User authentication
• Real-time buyer and seller messaging
• Transaction workflows
• Ratings and reviews
• User reporting
• Administrative moderation
• Row Level Security policies
• Recommendation functionality
• AI-assisted search experimentation
• Stripe test integration
• Responsive web interface
• Automated test suite with 39 test files and 187 passing tests
• Vercel deployment

Final Deliverable

Acadex became a working full-stack marketplace application covering considerably more than the minimum listing-and-search functionality expected from a university prototype.

The final system integrated database design, realtime features, authentication, access control, moderation, testing, UI design, and marketplace workflows into one cohesive application.

The project received an A+ grade.

Takeaway

Acadex was one of the projects that shifted my thinking from building individual features toward designing connected systems.

Features such as messaging, transactions, reviews, moderation, and permissions cannot be designed independently because they all depend on the same underlying entities and states.

The project also reinforced the value of automated testing in larger applications. As the number of interacting features increased, the test suite became increasingly important for making changes without silently breaking existing behaviour.