Uni-fetch

Need It? Ask Someone Who’s Going. UniFetch connects students with peers already heading their way to pick up, carry, or deliver what they need—on or off campus.

Comment

Inspiration

Every day on campus, students need to move small items from one location to another, while other students are already travelling around campus or heading outside. We realized that these two needs could be connected.

Instead of creating a separate delivery trip for every request, Uni-fetch V2 uses journeys that are already happening and connects them with students who need something delivered.

This inspired our core idea:

“Need It? Ask Someone Who’s Going.”

With V2, we wanted to take the original campus delivery concept further and build a more complete peer-to-peer delivery network for students, covering both within-campus and outside-campus deliveries.

What it does

Uni-fetch V2 is a peer-to-peer delivery platform that connects students who need something delivered with students who are already travelling in that direction.

V2 expands the original campus-focused concept with a complete delivery ecosystem.

Users can:

  • Create campus delivery requests
  • Browse available delivery requests
  • Accept requests as carriers
  • Earn credits for completing campus deliveries
  • Track delivery status
  • Use OTP verification for secure handoffs
  • Buy and manage credits
  • Create and browse outside-campus trips
  • Post outside-campus delivery requests
  • Negotiate delivery rewards through messaging
  • Accept and manage outside delivery requests
  • Track outside delivery status
  • Receive notifications
  • Rate and review completed deliveries
  • Use a dedicated demo/trial experience

The core campus flow is:

Request → Accept → Pickup → OTP Verification → Deliver → Earn Credits

The outside delivery flow extends this into:

Trip → Request → Negotiation → Acceptance → Payment → Delivery → Completion → Review

How we built it

We built Uni-fetch V2 as a full-stack web application with a focus on real-world workflows, authentication, database consistency, and secure peer-to-peer interactions.

Tech Stack

  • Next.js / React — Frontend and application framework
  • Supabase — Authentication, backend services, storage, and realtime functionality
  • PostgreSQL — Database and transaction management
  • TypeScript — Application development
  • CSS — User interface and responsive design
  • Supabase Realtime — Notifications and live updates

The database is designed around users, profiles, delivery requests, trips, outside deliveries, messages, payments, credits, notifications, and reviews.

We also implemented role-based access control and database-level security using Row Level Security (RLS).

A major focus of V2 was making the application behave like a real two-sided platform rather than simply being a delivery-request form.

What changed in V2

V2 builds on the original campus delivery idea and expands the platform significantly.

Campus Deliveries

Students can request items to be picked up and delivered within campus, while other students can accept those requests when they are already travelling in that direction.

The complete workflow includes:

Request → Carrier Acceptance → Pickup → OTP Verification → Delivery → Credit Reward

Outside-Campus Deliveries

V2 introduces deliveries beyond the campus.

Students can publish trips describing where they are travelling, while other students can request items to be carried along that route.

This creates a new workflow:

Trip → Delivery Request → Negotiation → Acceptance → Payment → Delivery → Completion

Negotiation & Messaging

Instead of forcing a fixed reward, outside deliveries allow users to negotiate the delivery reward and communicate through an integrated messaging flow.

Credits

The campus delivery system uses credits as an incentive mechanism.

Students can earn credits by successfully completing deliveries and manage their credit balance through the platform.

Trust & Verification

Because deliveries are handled by students, trust is a major part of the platform.

V2 includes:

  • Authentication
  • College ID verification
  • Verification status management
  • OTP-protected handoffs
  • Delivery status tracking
  • Reviews and ratings
  • Role-based access control
  • Row Level Security

Challenges we ran into

Building a Two-Sided Platform

The biggest challenge was designing the platform for both sides of the interaction.

A requester needs to create and track a delivery, while a carrier needs to discover, accept, complete, and receive rewards for that delivery.

We had to make sure that changes made by one user were correctly reflected for the other user.

Managing Complex Delivery States

As V2 introduced outside deliveries, the number of states increased significantly.

We had to handle transitions such as:

OPEN → NEGOTIATING → ACCEPTED → IN_PROGRESS → COMPLETED

while keeping the database and UI synchronized.

Building Trust Between Students

A peer-to-peer delivery platform needs mechanisms that make users comfortable handing items to other students.

We addressed this through:

  • College ID verification
  • OTP verification
  • Delivery status tracking
  • User ratings
  • Reviews
  • Authentication
  • Access control

Database Consistency

Managing credits, delivery states, payments, notifications, and user permissions required careful database design.

We also had to ensure that actions performed through the frontend matched the database rules and security policies.

Realtime Functionality

Notifications and realtime updates introduced another layer of complexity.

The application needed to keep users informed when important events occurred without requiring them to constantly refresh the page.

Testing the Complete Product

Instead of testing individual pages independently, we created an end-to-end testing workflow covering the complete product.

We tested:

  • Authentication
  • Demo mode
  • Signup and onboarding
  • Campus requests
  • Carrier flow
  • OTP verification
  • Incorrect OTP security
  • Credits
  • Outside trips
  • Outside delivery requests
  • Negotiation
  • Messaging
  • Payments
  • Notifications
  • Realtime functionality
  • Reviews
  • Admin access control
  • RLS
  • Mobile responsiveness

Accomplishments that we're proud of

We are proud that Uni-fetch evolved from a simple campus delivery idea into a much more complete peer-to-peer delivery platform.

Some of the features we are particularly proud of include:

  • Complete campus delivery workflow
  • Outside-campus delivery system
  • Trip-based delivery matching
  • Negotiation and messaging
  • Credit-based incentives
  • OTP-protected handoffs
  • College ID verification
  • Reviews and ratings
  • Realtime notifications
  • Authentication and access control
  • PostgreSQL database integration
  • Row Level Security
  • Responsive mobile experience
  • Demo/trial mode
  • Admin management functionality

Most importantly, we validated the complete V2 workflow through end-to-end testing against the live database, covering the major user journeys from onboarding to completed delivery.

What we learned

Uni-fetch V2 taught us that building a product is about much more than implementing individual features.

We learned how to:

  • Design a product around a real-world problem
  • Build a two-sided peer-to-peer platform
  • Design complex state-based workflows
  • Connect a React/Next.js frontend with Supabase and PostgreSQL
  • Implement authentication and authorization
  • Use Row Level Security for database protection
  • Build realtime notification systems
  • Handle payments and credit-based workflows
  • Design trust mechanisms for peer-to-peer interactions
  • Test complete user journeys with end-to-end testing
  • Build responsive experiences for both desktop and mobile
  • Iterate on an existing product without losing its original purpose

Our biggest takeaway was that existing movement can become useful delivery capacity when the right people are connected at the right time.

What's next for Uni-fetch

Our next step is to test Uni-fetch with real campus users and understand how students actually use the platform.

We want to measure:

  • Number of delivery requests
  • Successful delivery rate
  • Request-to-acceptance time
  • Outside-trip activity
  • Negotiation success rate
  • Repeat usage
  • Credit activity
  • User feedback
  • Delivery completion time

Based on these results, we plan to improve:

  • Delivery matching
  • Route-based recommendations
  • User trust mechanisms
  • Notifications
  • Negotiation experience
  • Overall delivery reliability

The long-term vision is:

Prove the campus use case → expand peer-to-peer delivery → improve matching → build a reliable student delivery network.

Built With

Share this project:

Updates

Submission history