Building a Trust Layer: Ratings in GusLift (Current State)

Kofi Amo-Antwi — Tue, 12 May 2026 17:45:28 +0000

GusLift is a campus rideshare app for students at our university. After shipping ride history and profile photos, the next obvious gap was trust: before someone gets in a car (or offers a seat), they want a signal that the other person has shown up and behaved well on past trips.

Data model: one row per person, per ride
Ratings live in Supabase in a ratings table keyed by the ride and who is giving the rating. Conceptually each row stores: which ride it was, who rated (from_user_id), who was rated (to_user_id), and an integer score from 1 to 5.

On the API side, POST /api/ratings validates that payload and upserts on conflict so a user can adjust their score for the same ride without creating duplicates. GET /api/ratings?user_id=… aggregates every rating received by that user and returns a rounded average plus a count, which is what powers the driver’s headline number on the home screen.

Ride history as the glue
The ride history endpoint already loads completed trips, riders, drivers, and cars. It now also pulls all ratings for those ride IDs and, for the currently logged-in user, attaches my_rating: the score they already submitted for that trip, if any.

That single field unlocks two different UX needs:

Lists can show a small “you rated this 4/5” pill without a second round-trip per row.
Home can ask “do you have any completed rides where you still have not rated?” by scanning history for the first ride with my_rating == null.
So history stays the source of truth for “what happened,” and ratings are a thin join on top.

Rider experience: celebrate, then ask
On the rider side, the flow is deliberately emotional before it is transactional. When a ride completes, a full-screen “Ride completed” overlay gives a moment of closure. After it dismisses, a bottom toast slides in: driver name, five stars, optional skip, and a link to ride details.

The toast is time-limited (progress bar + auto-dismiss), posts to POST /api/ratings on star tap, and shows a short thank-you state before sliding away. If the user skipped the prompt earlier, a best-effort check against ride history can still surface the toast for the oldest unrated completed trip so people are not stuck forever.

Ride detail (from history or from the toast’s “view details” path) also includes an inline star control so a rating can be submitted or changed later, using the same API.

Driver experience: reputation, not nagging (for now)
Drivers see their aggregate rating and count on the driver home hero when the GET endpoint returns data. History and detail screens can show the driver’s own past rating for a trip where that applies.

The backend is symmetric (any user can rate any counterparty on a ride), but the mobile prompts are currently centered on riders rating drivers. Reciprocal “rate your rider” flows are a natural follow-up now that POST and history enrichment are in place.

Building Ride History & Profile Customization in GusLift

Kofi Amo-Antwi — Tue, 05 May 2026 18:23:34 +0000

Ride History: Tracking Every Completed Trip
The idea behind Ride History is straightforward: after a driver marks a ride as complete, both the rider and the driver should be able to look back at all their past trips. Not just today's rides, but their entire account history.

On the backend, the API queries Supabase for every ride tied to the user's Google ID, filtered to only completed rides and ordered newest-first:

There's no date filter and no row limit -- it returns every completed ride the account has ever taken. On the mobile side, each ride renders as a card showing the date, route, pickup time, and the matched rider or driver's name. Users can also dismiss individual entries or clear the whole list, which sets a driver_hidden or rider_hidden flag without actually deleting data.

One challenge we ran into was understanding the ride lifecycle. Rides are created with status: "accepted" when a match is confirmed through our real-time matching worker. They only flip to "completed" when the driver explicitly taps "Complete ride" on their dashboard. This means the history screen is intentionally limited to trips both parties actually finished -- not just ones that were matched.

Profile Image Picker

We also built a reusable PhotoPicker component that lets both riders and drivers set a profile photo during setup. It uses Expo's ImagePicker API to request gallery permissions, open the device photo library, and crop to a 1:1 square:

The selected image is sent to the backend as part of a FormData payload during registration, where it gets uploaded to Supabase Storage and the public URL is saved to the user's profile. This was trickier than expected because React Native and web handle file blobs differently -- on web we can pass the raw File object, but on native we pass a { uri, name, type } descriptor that fetch knows how to stream as multipart form data.

The profile photo then shows up across the app: in the rider's home screen header, in the driver's rider list, and anywhere a user's identity is displayed.

Author: Kofi Amo-Antwi

DEV Community: Kofi Amo-Antwi

Building a Trust Layer: Ratings in GusLift (Current State)

Building Ride History & Profile Customization in GusLift