CreditSwap

Signup Page
Login Page
Profile Page
Marketplace Page
Create Listing Form
Listing Details Page
Swap Details Page

Project Description

Problem Statement

In residential life, students often end up with unused meal credits while others run short. This creates a practical mismatch: one resident may miss meals because they are low on credits, while another resident loses credits simply because they cannot use them in time. Our prototype directly targets this problem by creating a structured way for residents to post offers and requests for credits, instead of relying on scattered word-of-mouth chats or informal arrangements. The core issue we wanted to solve was the inefficient peer-to-peer redistribution of meal credits within residential communities.

This matters in the context of residential life because meal credits are tied closely to daily living, budgeting, and convenience. When residents cannot easily find someone to exchange with, credits may be wasted, and students who need extra support may struggle unnecessarily. In a residential setting where students live, eat, and interact in the same community, a lightweight exchange platform can improve both resource usage and peer support.

Inspiration

Our project was inspired by a very real and familiar residential-life problem: meal credits often go to waste while other students may be short on them. In many residences, these exchanges happen informally through word of mouth, messaging groups, or personal networks. That system is inconvenient, inconsistent, and often inaccessible to students who do not know the right people to ask.

We saw an opportunity to make this process more transparent and community-driven by turning an informal social process into a simple platform. Instead of letting unused credits expire or forcing students to rely on scattered chats, we wanted to build a dedicated space where supply and demand could meet more efficiently.

Our Solution

Our solution is a residential credit-exchange platform that lets students post listings when they want to offer or request meal credits, browse active listings, and initiate swaps with other residents. The app separates listings into tabs for offers, requests, and personal listings, making the exchange process clearer and more organised than ad hoc messaging. Once a user finds a suitable listing, they can propose a swap, contact the other party, and move the transaction forward through a defined workflow instead of handling everything manually.

The solution also adds safeguards that make the platform more practical and trustworthy. Listings automatically expire after a set period, self-swaps are blocked, daily listing creation is rate-limited, and swap creation checks whether the giver has enough credits and whether the receiver would exceed the allowed cap. This helps reduce spam, invalid transactions, and abuse, while keeping the system simple enough for students to use casually. In addition, the data model includes swap messages and notifications, which supports smoother coordination between residents after a match is found.

How We Built It

The prototype was built as a full-stack web application using Next.js, React, TypeScript, Prisma, and SQLite. We used React to build the user interface, Prisma to model and manage the application data, and SQLite for lightweight local persistence during development. We also used Zod for request validation, which helped ensure that incoming data was properly structured before being processed by the backend.

At the data level, the application revolves around several main entities: User, Listing, Swap, and SwapMessage. A user can create listings, a listing can either be an offer or a request, and a swap is created when another user responds to that listing. Messages are attached to swaps so that both sides can coordinate directly within the system.

Operationally, the flow is straightforward. Users browse listings by type, create their own listings, and propose swaps on listings that match their needs. When creating a listing, the backend validates the payload and enforces a daily posting limit before saving it with an expiry timestamp. When creating a swap, the backend checks that the listing is still active, prevents self-swaps, verifies credit constraints, marks the listing as matched, and creates the associated swap record in a transaction. This helped us make the MVP technically solid even without implementing a complex matching engine.

How It Works

The platform works like a lightweight marketplace for residential meal credits. Residents can post either an offer if they have excess credits or a request if they need credits. Other users can browse these listings and respond when they find a suitable match. The system then facilitates the exchange by creating a swap record and allowing communication through messages.

The design keeps the interaction simple while adding enough structure to make it safe and usable. By combining listing expiry, credit checks, transaction logic, and user-specific views, the system gives students a much clearer way to coordinate exchanges than scattered chat messages or informal networks.

Challenges We Faced

One of the main challenges was translating a social and informal behaviour into a structured digital workflow. In real life, credit exchanges are flexible and sometimes ambiguous, so we had to decide how much structure to impose without making the system feel too rigid. That meant carefully designing the listing flow, swap logic, and messaging system so that it remained intuitive for users.

Another challenge was enforcing constraints fairly. We had to think about what should happen if a user tries to swap with themselves, if a listing has already expired, or if a transaction would create an invalid credit state. This pushed us to design stronger backend validation and transaction-based logic to prevent edge cases and maintain consistency.

We also had to balance ambition with feasibility. While more advanced features like auto-matching or recommendation systems would be valuable, we chose to prioritise a reliable core workflow first. This helped us stay focused on building an MVP that actually works, rather than overcomplicating the system too early.

What We Learned

Through this project, we learned that many everyday residential-life problems are not necessarily caused by a lack of resources, but by inefficient coordination. A relatively simple platform can create meaningful value if it improves how people discover one another’s needs and surpluses.

We also learned the importance of designing for both user experience and system integrity. It was not enough to make the interface look clean; we also needed to ensure the backend could enforce rules reliably and handle realistic edge cases. From a technical perspective, we gained hands-on experience in connecting frontend actions to backend routes, modelling relational data with Prisma, validating inputs, and managing workflows that involve multiple entities and conditions.

More broadly, this project showed us how software can improve small but important parts of student life. Even a focused MVP can have real impact when it addresses a problem students actually face in their day-to-day routines.

Impact & Feasibility

This project can improve student experience by reducing wasted meal credits, helping students who run short on credits, and making exchanges faster and less awkward. Instead of broadcasting needs in residence chats or relying only on personal networks, residents get a dedicated and transparent platform for matching supply and demand. That can make residential life more efficient and more community-driven at the same time.

The idea is also feasible to implement realistically. The current codebase already includes the main building blocks needed for an MVP: listing creation, listing browsing, swap creation, validation, expiry handling, messaging, and demo seed data. It uses a relatively simple and maintainable stack, which makes it practical to iterate on quickly. Because the logic is already centralised in backend routes and Prisma models, the project can be extended in future with features such as smarter matching, hall-specific filtering, moderation tools, analytics, or AI-assisted recommendations.

A Simple Way to Think About the Platform

At a high level, the platform is trying to reduce mismatch between students who have excess credits and students who need them. In a simplified sense, if we let

$O$ = number of available credit offers
$R$ = number of active credit requests
$M$ = number of successful matches

then the system aims to maximise $M$ such that

$$ M \leq \min(O, R) $$

In other words, the platform creates value by increasing the number of successful matches between existing supply and demand. While our current MVP uses a rule-based workflow rather than a mathematical optimisation engine, the long-term goal is the same: reduce waste and improve access by matching residents more efficiently.