DEV Community: Inside GusLift

Week 7: How GusLift Handles Payment Without a Payment Processor

Amanuel Demissie — Sat, 23 May 2026 10:29:57 +0000

#mobiledevelopment #backenddevelopment #database #infrastructure

Campus rideshare is informal. Nobody wants to enter a card number. But "figure it out after the ride" doesn't work either — it creates friction and confusion at drop-off. We needed a payment flow that's lightweight, works with Venmo and CashApp, and doesn't require GusLift to touch money.

Here's what we built.

Fare Calculation

Fares are computed from the straight-line distance between two campus buildings using the Haversine formula. The base fare is $1.00. Distance adds $0.75 per mile on top. All 20 Augustana buildings have precomputed lat/lng coordinates, so the fare for any route is deterministic and computable on the client with no API call.

The rider sees an estimated fare on the home screen before they even request a ride, calculated from their saved commute. That number is confirmed again on the ride detail screen once a match is made.

Driver Payout Settings

Drivers configure their preferred payment method once — Venmo handle, CashApp tag, Zelle phone number, or "cash." This is stored in a driver_payment_settings table in Postgres. When a rider views a confirmed ride, they see which method the driver accepts and the amount to send.

We also scaffolded Stripe Connect routes for future use, but that path isn't active. For now, all transactions happen off-platform.

The Verbal Code

The rider generates a 4-digit code through the app after paying. The code is written to the Rides table and marked code_issued. At drop-off, the rider reads the code to the driver, who enters it in the driver ride detail screen. The backend verifies the code matches, marks the ride payment_verified, and that's it.

There's no escrow, no hold, no dispute mechanism. The code is purely a lightweight confirmation signal: the rider clicked "I paid" and got a code; the driver confirmed they heard it. For a campus app where both sides know each other by face, that's sufficient.

Schema Changes

Four new columns on Rides: fare_cents, payment_code, payment_status, payment_method. One new table: driver_payment_settings. The ride history screens for both roles now surface payment status on completed rides.

What's Left

The flow assumes the rider pays before the ride ends and that the driver actually checks the code. There's no enforcement if either side skips. For pilot scale — a few dozen rides a week — that's acceptable. Rate limiting on code generation and expiry on unverified codes are the obvious next additions.

Week 7: How GusLift Shows Your Route in Real Time

Amanuel Demissie — Sat, 23 May 2026 10:25:24 +0000

#reactnative #maps #crossplatform #mobiledevelopment

Every ride request involves two locations. The matching screen was showing those as text. Adding a map that actually shows both pins — pickup in green, dropoff in red, other participants in blue — is a small change in concept but a surprisingly tricky one in practice.

Here's how we got there.

The Native Maps Dead End

The first attempt used react-native-maps backed by Google Maps. It worked on iOS and Android simulators. It didn't work on web at all, and the native build requires an API key wired into the native layer, which adds friction every time someone clones the repo. After getting it running, we ripped it out entirely.

What We Replaced It With

The map is now a WebView embed running Leaflet over OpenStreetMap tiles. On web it renders as a plain <iframe srcDoc>. On iOS and Android it uses react-native-webview. Same HTML, same behavior, no API key required, no native build step.

The map HTML is generated at runtime. We compute a bounding box from all the pins, set the center and zoom dynamically, and inject the markers as JavaScript into the Leaflet page before it loads. Each pin is a custom SVG — a teardrop shape with a white circle — colored by role.

The Coordinate Layer

Campus buildings don't have addresses that geocoding handles well. We precomputed lat/lng for all 20 Augustana buildings from OpenStreetMap and stored them in a static lookup table — campusCoords.js. Every pin resolves through that table. No geocoding at runtime, no API call, no latency.

Where Maps Appear

RouteMap is a single reusable component that takes pickup, dropoff, and an optional extraMarkers array. It appears on:

The rider and driver waiting rooms (your own route while you wait)
The ride detail screens (confirmed route after match)
The available riders/drivers screens (driver sees all rider pickup pins; rider sees the driver's pickup pin in purple once matched)

The matching worker was extended to broadcast pickup_loc alongside to_location over WebSocket so that map pins for other participants are available on match screens without an extra DB fetch.

What Didn't Change

State, matching logic, and the Durable Object model are untouched. The map is purely display — it reads locations already present in the app state and renders them.

Strengthening Ride Matching, Notifications, and Schedule Management

Nathan Sisay — Fri, 22 May 2026 03:17:59 +0000

For our last week, focused on improving session persistence and preparing GusLift for broader platform support. This week, we continued improving the core ride-sharing experience by working on notifications, routing, schedule management, ride matching, and user interface consistency.

Improving Push Notifications

One major focus this week was improving push notification support.

Push notifications are important for a ride-sharing app because riders and drivers need to receive updates quickly. For example, a rider should know when a driver responds to a ride request, and a driver should know when there is activity related to a potential ride.

To support this, the app was configured to work with Expo notifications and Firebase notification services for Android.

On the backend, notification token handling was added so the app can store device push tokens. This allows the system to know where notifications should be sent when ride or matching events happen.

The matching worker was also updated to support push notification behavior, helping connect real-time ride matching events with user-facing alerts.

Why Notifications Matter

Without notifications, users would need to constantly keep checking the app for updates.
That would make the ride experience slower and less reliable.
By adding notification support, GusLift can begin moving toward a more real-time experience where users are alerted when something important happens.

This is important for matching riders and drivers, since timing matters when coordinating rides.

Improving Routing and Login Flow

Another major area of work was improving how users move through the app after logging in.

Several routing fixes were made so riders and drivers land on the correct screens based on their role and setup status.

For riders, the app was updated so they consistently land on RiderHome instead of being sent to the older RequestRide screen. Older entry points to the previous request screen were removed or redirected.

A new route helper was also added to centralize user routing logic. This makes the app easier to maintain because routing decisions are handled in one place instead of being scattered across multiple screens.

Improving Ride Matching Visibility

This week also included improvements to the ride matching experience.

The app now shows pending driver matches more clearly on rider home and scheduled rides screens. This helps riders understand when a match is waiting for action instead of hiding it deeper in the app.

There were also fixes to prevent drivers from re-selecting riders who already rejected them.This makes the matching process feel more logical and prevents confusing repeat interactions between riders and drivers.

Updating Schedule Management

Schedule management was another important improvement.
The older change-schedule flow was replaced with a cleaner view and edit schedule experience. This gives both riders and drivers a better way to manage their availability and planned rides.
The schedule screens were also connected more cleanly from the rider and driver home pages.

This matters because scheduling is one of the core features of GusLift. Riders need to plan rides, and drivers need to manage when they are available.

Improving Time Display and Ride History

Many commits focused on fixing time display issues.
Waiting room times, manual ride times, and ride history display were updated so users see more accurate and consistent information.
This is especially important for a ride-sharing app because incorrect time information can quickly make the experience confusing.
Ride history was also improved so past ride information displays more reliably for users.

User Interface Improvements

We also made a lot of visual and layout improvements.
Rider screens were restyled for better color and layout consistency. Home screens and waiting room screens were updated to better match the app’s brand palette.
Quick-action buttons were added to rider and driver hero cards, and a new logo was added to the homepage.
These changes help the app feel more polished and easier to navigate.

Before deployment, we plan on:

Testing push notifications across more devices
Improving the full rider-driver matching flow
In app chat functionality
Connecting payment status more closely with ride status
Continuing to clean up time and schedule logic
Improving reliability of ride history and scheduled ride screens

Stripe Payment and Processing

Nathan Sisay — Mon, 18 May 2026 05:37:29 +0000

Since GusLift is a ride-sharing platform, payments are an important part of the user experience. Riders need a simple and secure way to complete payment, while the backend needs a reliable way to track payment status for each ride. To begin this process, we integrated Stripe Checkout into the project.

Implementing Stripe Checkout

One of the biggest goals so far was to create a payment flow that could be tested safely during development.
To do this, we added a backend route that creates a Stripe Checkout Session. When the mobile app requests a payment, the backend communicates with Stripe and receives a hosted checkout URL.
The user can then open that Stripe-hosted page and complete the payment using a test card.
This approach is useful because Stripe handles the secure payment form, card validation, and checkout experience. GusLift does not need to directly collect or store sensitive card information, which makes the implementation safer and easier to maintain.

Connecting Payments to Rides

Another important part of the payment system was making sure payments could be connected back to a specific ride.
When a checkout session is created, GusLift can include ride information such as:
-Ride ID
-Rider ID
-Ride label
-Customer email
-Payment amount

This information allows the backend to keep track of which payment belongs to which ride.
We also added support for storing payment records in a RidePayments table. This table keeps track of information such as the Stripe checkout session ID, payment intent ID, amount, currency, checkout URL, and payment status.
This gives the app a clearer record of what happened during the payment process.

Handling Payment Status

After a user finishes checkout, Stripe redirects them to a success page. GusLift then retrieves the checkout session details from Stripe and updates the payment record.
If the payment was completed successfully, the record can be marked as paid. If checkout is canceled, the payment can be marked as canceled instead.
Tracking these states is important because ride status and payment status are separate things.
For example, a ride could be accepted, but the payment may still be pending. Keeping those states separate makes the system easier to reason about as the app grows.
Building the Mobile Checkout Screen
On the mobile side, we added a Stripe Demo Checkout screen.
This screen checks whether the backend payment configuration is ready before allowing the user to continue. If Stripe is configured correctly, the user can tap a button to launch checkout.
For the current development version, the checkout uses a fixed demo amount of $5.00.
The mobile screen also supports passing ride-related information into the checkout flow, which helps prepare the app for real ride payments later.

Why Stripe Matters

Stripe is useful for GusLift because it allows us to build payment processing without needing to manage sensitive payment details ourselves.
Instead of building a custom card form from scratch, we can use Stripe’s hosted checkout flow. This improves security, reduces complexity, and lets the team focus more on the ride-sharing experience.
It also gives us a strong foundation for future payment features, such as authorizing payment when a rider confirms a driver and capturing payment after the ride is completed.

Some of the next milestones include:

Connecting payment more directly to confirmed rides
Improving success and cancel handling in the mobile app
Adding webhook support for more reliable payment updates
Moving from simple checkout payments toward authorization and capture
Testing the full ride flow from request to completed payment

By integrating Stripe Checkout, adding backend payment routes, and storing payment records, the app now has a basic but functional payment flow. While there is still more work to do before payments are production-ready, this is an important step toward making GusLift feel like a complete ride-sharing platform.

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 Push Notifications in GusLift

Abdul-Salam Zakaria — Tue, 12 May 2026 17:37:00 +0000

GusLift connects student drivers with riders heading the same way. The matching itself happens over a WebSocket, which is fine when both people are staring at the app. The problem is that most of the time they aren't. Someone requests a ride, locks their phone, and the driver on the other side of campus has no idea anyone is waiting.

This post walks through how push notifications were wired into GusLift across the three services that make up the product: the Expo mobile app, the Next.js backend on Cloudflare, and the matching worker (a Durable Object on Cloudflare Workers).

The shape of the problem

There are exactly two moments where a push notification meaningfully changes user behavior:

A driver picks a rider from the waiting list. The rider needs to know to open the app and accept.
The rider accepts. The driver needs to know the ride is locked in.

Everything else, like seat counts updating or another driver joining the slot, is noise. Sending push for those would train users to ignore the notifications they actually need. So the scope was deliberately narrow: two event types, both tied to a confirmed action on the other side.

Architecture in one diagram

  mobile (Expo)                backend (Next.js)              matching-worker (DO)
  -------------                ----------------               --------------------
  registerCurrentUser     -->  POST /api/notifications/token
  PushToken()                  upsert into PushTokens
                                                              MatchingRoom event:
                                                                rider reserved
                                                                  or match accepted
                                                              -->  sendMatchPush
                                                                   Notification()
                                                                   reads PushTokens
                                                                   POST exp.host
  Notifications handler   <--  (Expo push service)            <--
  routes user to screen

The mobile app owns token acquisition. The backend owns token storage. The matching worker owns dispatch. None of them know about the other two beyond a shared Supabase table and a stable contract on the wire.

The storage layer

The whole feature hinges on one table:

create table if not exists public."PushTokens" (
  id bigint generated by default as identity primary key,
  user_id text not null references public."User"(id) on delete cascade,
  token text not null unique,
  platform text null,
  is_active boolean not null default true,
  created_at timestamp without time zone not null default now(),
  updated_at timestamp without time zone not null default now()
);

A few choices worth calling out:

token is unique, not (user_id, token). The same physical device could in theory be reused across user accounts (think shared family phone, or a dev account on a personal device), and we want the latest user to claim it. Upserts use onConflict: "token" so the row gets reassigned cleanly instead of duplicating.
is_active is a boolean rather than deleting rows. When Expo reports DeviceNotRegistered we mark the row inactive. This keeps history useful for debugging "why didn't I get a push" complaints without leaking junk into the active set.
A small set_push_tokens_updated_at trigger keeps updated_at honest on every write. Push tokens rotate, especially on iOS, so the freshness of a token row is something we look at when triaging.

Indexes are on user_id and on (user_id, is_active). The hot read path is always "give me the active tokens for this one user," which the composite index covers.

Registering a token from the mobile app

The mobile side lives in mobile/lib/pushNotifications.js. It runs on app start and also whenever the app comes back to the foreground:

useEffect(() => {
  void registerCurrentUserPushToken();
  const sub = AppState.addEventListener("change", (state) => {
    if (state === "active") {
      void registerCurrentUserPushToken();
    }
  });
  return () => sub.remove();
}, []);

The "on resume" call matters more than it looks. Tokens can be revoked or rotated while the app is backgrounded (an OS update, a permission change, a reinstall), and Expo will hand back a different value next time you ask. Re-registering on foreground is the cheapest way to stay correct.

The registration function itself is deliberately defensive. It walks through these steps and bails out loudly at any point that fails:

Skip on web entirely. There is no Expo push token there.
Look up the user in AsyncStorage. No stored @user, no registration, since we'd have nowhere to attribute the token.
On Android, create the default notification channel with MAX importance. Without this, notifications arrive but never make a sound or appear as a heads-up.
Ask for permissions, requesting them if not already granted.
Call getDevicePushTokenAsync for logging, then getExpoPushTokenAsync with the EAS projectId from Constants.expoConfig.extra.eas. The Expo token is what the backend actually stores.
POST it to ${BACKEND_URL}/api/notifications/token with an x-user-id header.

Every step logs a [push] ... line. That has paid for itself many times over. When a user reports "I never got the notification," the first question is always "what does logcat say at app start," and the answer comes from these breadcrumbs.

Sign-out goes through deactivateCurrentUserPushToken, which calls DELETE on the same endpoint. The server marks the row inactive rather than deleting it. If the device immediately signs back in we re-activate by upsert, no row churn.

The backend endpoint

The token route is one file: backend/app/api/notifications/token/route.ts. It exposes POST and DELETE.

The auth story is intentionally simple. The handler accepts a user id in three ways, in this order:

const fromHeader = request.headers.get("x-user-id")?.trim();
if (fromHeader) return fromHeader;

const bearer = parseAuthHeaderUserId(request.headers.get("Authorization"));
if (!bearer) return bodyUserId?.trim() || null;

// fall back to Supabase auth.getUser(bearer)

x-user-id is what the mobile app sends today because we already have a verified Google user id in AsyncStorage after login. The Authorization: Bearer ... path is there for when we move the rest of the API behind Supabase JWTs. Keeping both paths in one helper means we can flip the flag on auth without touching the notifications surface.

The POST body looks like:

{ "token": "ExponentPushToken[...]", "platform": "ios" }

The handler normalizes both fields (trim, lowercase platform), then upserts on token. That's the entire write path. The service role key lives in SUPABASE_SERVICE_ROLE_KEY, since this endpoint needs to write across users without going through RLS.

DELETE is almost the same shape. If the body includes a specific token, only that row gets deactivated. If it doesn't, every active token for that user gets flipped off. The "deactivate all" variant is what runs on sign-out, so a shared device doesn't keep buzzing the previous user.

Dispatching from the matching worker

The matching worker is a Cloudflare Durable Object. Each ride slot (location + day + start_time) is its own room, and inside that room there's a small state machine driving who is waiting, who is reserved, and who is confirmed. The push dispatch is hooked into exactly two transitions in MatchingRoom.ts:

if (this.shouldSendPush("driver_selected_rider", ev.rider_id, ev.driver_id)) {
  void sendMatchPushNotification(this.env, {
    recipientUserId: ev.rider_id,
    eventType: "driver_selected_rider",
    riderId: ev.rider_id,
    driverId: ev.driver_id,
  });
}

and

if (this.shouldSendPush("rider_confirmed_match", ev.rider_id, ev.driver_id)) {
  void sendMatchPushNotification(this.env, {
    recipientUserId: ev.driver_id,
    eventType: "rider_confirmed_match",
    riderId: ev.rider_id,
    driverId: ev.driver_id,
    rideId: ride.id,
  });
}

Two things to notice. First, the call is fire and forget (void). The state machine should never wait on Expo, and a failed push should never break a match. Second, shouldSendPush gates every call.

Why dedupe is necessary

Durable Objects can replay events. State recovery, client reconnects, even a rider rapidly tapping "accept" can cause the same logical transition to fire twice. Without dedupe, the user gets two identical notifications back-to-back, which feels broken even though it isn't.

shouldSendPush keeps an in-memory map keyed by ${slotKey}:${riderId}:${driverId}:${eventType}:${bucket}, where bucket = floor(now / 30s). Anything inside the same 30-second window for the same pair and event type is dropped. The map self-prunes anything older than 2 minutes, so it doesn't grow unbounded.

This lives in the DO instance memory rather than Supabase. Cross-instance dedupe isn't needed because each slot only has one DO, and that DO is the only sender for the slot.

Talking to Expo

pushNotifications.ts in the worker is the actual sender. It does three things:

Fetch active tokens for the recipient out of PushTokens. If a user has multiple devices, all of them get the message.
Build a message per token and POST the array to https://exp.host/--/api/v2/push/send. The payload sets sound: "default", a short human title and body, and stuffs the event metadata into data.
Walk the response tickets. Any token that comes back with DeviceNotRegistered gets bulk-updated to is_active = false.

The cleanup step is the part that's easy to forget. Without it, a user who reinstalls the app accumulates stale token rows, every push attempt eats a slot in the array sent to Expo, and you get rate-limited for ghosts. Treating DeviceNotRegistered as a hint to deactivate keeps the active set healthy with zero ops work.

The data payload is the contract with the mobile app:

data: {
  type: params.eventType,            // "driver_selected_rider" | "rider_confirmed_match"
  rider_id: params.riderId,
  driver_id: params.driverId,
  ride_id: params.rideId,            // present only on rider_confirmed_match
}

Deep-linking from a tapped notification

A push that just makes a sound is half a feature. The reason the data payload includes type is so the mobile app can route the user to the correct screen when they tap the notification, instead of dropping them on the home screen.

That listener lives in mobile/app/_layout.js:

const subscription = Notifications.addNotificationResponseReceivedListener(
  (response) => {
    const data = response?.notification?.request?.content?.data || {};
    const type = typeof data?.type === "string" ? data.type : "";
    if (type === "driver_selected_rider") {
      router.push("/rider/ScheduledRidesRider");
      return;
    }
    if (type === "rider_confirmed_match") {
      router.push("/driver/ScheduledRidesDriver");
    }
  },
);

The setNotificationHandler above it controls in-app behavior. We show the banner and the list entry, but don't play a sound or set a badge while the app is foregrounded. The reasoning is that if the user is already in the app, the WebSocket has already delivered the same information through the UI, and an extra sound on top of that is annoying.

How we fixed push notifications

Everything above describes the design as if it landed clean. It didn't. The first end-to-end test had token registration logs that looked perfect, no notifications arriving on the Android device, and a matching flow that broke after a successful match (the rides screen rendered empty). What follows is the actual debug trail.

The five things that were broken

1. Wrong EAS project ownership. The Expo project ID baked into app.json belonged to an account I no longer had access to. npx eas credentials returned Entity not authorized.

Fix: removed the old extra.eas.projectId, ran npx eas init to mint a fresh one under my account, rebuilt the app.

2. Missing FCM credentials on the new Expo project. Expo can issue an ExponentPushToken[...] without FCM credentials, so registration looked fine, but https://expo.dev/notifications returned InvalidCredentials: Unable to retrieve the FCM server key.

Fix: in Firebase Console under Project Settings, Service accounts, Generate new private key (not google-services.json, that's a different file). Uploaded it via npx eas credentials, Android, Google Service Account, FCM V1.

3. Stale tokens from the old project still in the DB. After re-creating the project, the old ExponentPushToken[...] rows in PushTokens were still is_active = true. Mixing them with the new token in a single Expo batch made the whole send return 400.

Fix: delete from "PushTokens" where user_id = '...'; then re-open the app to register a fresh token under the new project.

4. Backend swallowed Expo's error reason. pushNotifications.ts only logged the status code, so 400s were opaque.

Fix: added the response body and the token list to the error log so future push failures self-explain.

5. Notification tap went to the wrong screen. _layout.js routed driver_selected_rider to ScheduledRidesRider (upcoming rides), not the accept/reject card.

Fix: routed to /rider/AvailableDrivers with driverId from the push payload.

6. Tap stacked a duplicate AvailableDrivers screen. When the rider was already on AvailableDrivers (because the in-app match_request had already routed them there with full driver details), tapping the notification called router.push again, pushing a second copy on top, hydrated only with driverId, so it showed "Unknown Driver".

Fix: added a pathnameRef guard, skip the navigation if already on the target screen. Same guard for the driver-side rider_confirmed_match notif.

Side bugs found and fixed along the way

Empty upcoming-rides screen after accept. Worker wrote ride_date in UTC; backend queried in local time. Aligned the writer to use local-date components.
Rider showing 3x on driver's screen. Rider's WS reconnects re-sent rider_request, and handleRiderRequest had no dedupe. Now ignored if the rider is already waiting or in a pending match.
INVALID_STATE_ERR from MatchingContext.send. The ?. only guarded null, not CONNECTING/CLOSING readyState. Now checks readyState === 1.

The actual checklist for end-to-end push

Working backwards from the bug list, the requirements turned out to be:

Own the Expo project (account access).
Upload an FCM V1 service-account key to it (so Expo can deliver to Android).
Have a fresh, valid token registered in your DB.
Have the server actually call the send (it was, the matching flow does).
Route the tap somewhere useful, without stacking duplicate screens.

Items 1 and 2 are environmental and have nothing to do with the code. Items 3 through 5 are the ones the codebase has to keep honest forever. Most of the time when push "stops working" for a user later, the cause will be one of those three.

What it cost, what it bought

In code, this feature is small. One SQL file, one Next.js route, one mobile lib, one worker module, and a handful of call sites in the existing matching room. The whole thing is a few hundred lines.

What it bought is the ability to stop telling users "keep the app open while you wait." That single sentence was the biggest source of friction in early testing, and it didn't go away until tokens, dispatch, and dedupe were all in place.

A few things would be worth picking up later:

Server-side dedupe at the Supabase layer would let us survive a DO restart without re-sending. Today the 30-second bucket protects the common cases but isn't bulletproof across instance churn.
The Authorization header path in the token route is wired up but not exercised. Moving the mobile client onto Supabase JWTs would let us drop x-user-id and the trust assumption that goes with it.
Right now the notification title and body strings are hardcoded in the worker. A small templating layer would make it cheaper to localize and to A/B test the copy.

None of those block shipping. The current setup has been quietly delivering both event types reliably, deactivating dead tokens on its own, and routing taps to the correct screen, which is exactly the bar I wanted before writing about it.

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

Week 6: How GusLift Matches Rides in Real Time

Abdul-Salam Zakaria — Sun, 15 Mar 2026 13:41:03 +0000

Every school morning, a few drivers leave their dorms for campus, and a bunch of riders need seats. The core problem: match them fast, in the right direction, before the window closes.

Here's how the matching engine actually works.

The Matching Room Abstraction

We don't run one global pool. We partition by location, day, and departure time. A room key looks like:

Westie:mon:08:00

That string becomes the identity of a Cloudflare Durable Object(DO), a live, in-memory process that owns all real-time state for that slot. Everyone heading from Westie at 8am Monday shares one room. Leaving at 10:30? Different room entirely. This keeps each instance small and focused. The matching room doesn't know or care about any other departure window.

Getting Into the Right Room

When a user opens the app, a Cloudflare Worker handles the request. It authenticates, resolves the user's schedule, generates the slot key, and forwards the WebSocket connection to the right DO. The Worker is stateless, purely a router. All the interesting state lives in the object it points to.

What the DO Tracks

Four things:

drivers — map of driver ID → seats remaining
riders_waiting — FIFO queue of riders requesting a ride
pending_matches — riders a driver has selected but who haven't confirmed
connections — live WebSocket handles, one per user

Every state change broadcasts to all connected clients. The frontend is a mirror of what the DO holds, nothing more.

The Flow

Driver goes online → sends driver_online with seat count → registered in the room, broadcast to everyone. Rider wants a seat → sends rider_request → added to the queue.

Driver picks someone. That rider moves out of riders_waiting into pending_matches and gets a match_request pushed to their socket. They have 30 seconds to accept. No response → back to the queue. They accept → seat decrements, ride written to Postgres, room updates for everyone.

The part that could get hairy is concurrent events — two drivers selecting the same rider at the same time. The DO's single-threaded execution model handles that without any extra locking. One message at a time, in order. It's one of the legitimately nice properties of this architecture.

Why Durable Objects

Serverless and WebSockets are a bad pairing by default. Serverless assumes requests are stateless and short-lived; a WebSocket is neither. DOs give you a persistent, single-threaded process with in-memory state that survives across events. For a campus app where load is concentrated in a 20-minute morning window, you get rooms that spin up when needed and hibernate when not. No idle infrastructure, no connection hand-off problems.

What's Left

A few open problems the current design doesn't address: drivers who cancel after a match is accepted, rooms that never get cleaned up after their departure window passes, and rate limiting on socket events. None of these tasks is difficult in principle. They just weren't the initial challenges.

Week 5: Improving Session Persistence and Planning Cross-Platform Support

SundeepShrestha — Sat, 07 Mar 2026 00:39:33 +0000

Last week, we introduced GusLift and focused on building the authentication system that allows users to log in using their Google accounts. This week, we continued working on improving how user sessions are handled within the app and started planning how the application will support multiple platforms.

Our main focus was improving session persistence and thinking about how the platform will eventually run across iOS, Android, and web environments.

Improving User Session Management

One challenge that often appears in mobile applications is how to handle user sessions after authentication. Ideally, users should not have to log in every time they open the app, but at the same time, sessions should not remain active indefinitely for security reasons.

To address this, we implemented Async Storage to store user session data locally on the device.

When a user successfully signs in using Google authentication, key information about the session is saved locally. This allows the application to recognize returning users and automatically keep them logged in.

Currently, sessions are configured to remain active for approximately seven days before requiring the user to authenticate again.

This approach improves usability while still maintaining a reasonable level of account security.

Why Async Storage Matters

Async Storage allows the app to persist small pieces of information locally on a user’s device.

In the case of GusLift, it is used to store session-related information so that users can continue using the app without repeatedly signing in.

Without this feature, every time a user closed and reopened the application, they would need to authenticate again, which would make the experience frustrating.

By storing session data locally, the app can restore the user's session quickly when the application launches.

Planning Cross-Platform Support

Another goal for the GusLift project is ensuring that the application can run across multiple platforms.

Since the project is being built using React Native with Expo, we have the flexibility to target several environments with a single codebase.

Our long-term objective is to support:

iOS devices
Android devices
Web browsers

Supporting multiple platforms increases accessibility and allows users to interact with the platform in whichever way is most convenient.

Why Cross-Platform Development Matters

Building separate applications for each platform can significantly increase development time and maintenance complexity.

Using React Native allows the team to reuse much of the same codebase across different environments, which simplifies development and makes future updates easier to manage.

This approach also allows us to test features more quickly as the project continues to evolve.

Next Steps

With authentication and session persistence in place, the next stage of development will focus on building the core functionality of the platform.

Some of the next milestones include:

Designing the ride request workflow
Implementing driver availability
Building the ride matching logic
Improving the user interface

As the project progresses, we will continue documenting the development process and technical decisions in these weekly updates.

Final Thoughts

The improvements made this week help create a smoother user experience by allowing users to remain logged in while also preparing the application for broader platform support.

Although the project is still in the early stages, these foundational components will make it easier to build the core ride-sharing functionality in the coming weeks.

Week 4: Understanding what GusLift Is

SundeepShrestha — Sat, 07 Mar 2026 00:09:31 +0000

Many students at Universities or Colleges rely on friends, rideshare services, or campus transportation to get around. While services like Uber and Lyft exist, they are not always practical for short trips around campus or nearby areas.

For example, a student might need a ride from their dorm to an academic building, a nearby apartment, or a grocery store. In situations like this, requesting a full rideshare service often feels unnecessary or expensive.

GusLift started as an idea to solve this problem by creating a campus-focused ride-sharing platform designed specifically for students.

The goal is simple: Make it easier for students to connect with others who are already driving somewhere nearby, while keeping the platform limited to trusted users within the college community.

The Idea Behind GusLift

Unlike traditional ride-sharing apps that are open to anyone, GusLift is designed to be restricted to verified users from the campus community.

This approach helps create a safer and more trusted environment where students know they are interacting with other members of their school community.

Instead of requesting rides from strangers, users can connect with other students who are already heading in the same direction.

The long-term goal is to create a small, efficient transportation network within the campus ecosystem.

Early concept for the GusLift interface.

What We Built So Far

This week, we focused on setting up the authentication system for the application.

Authentication is an important part of GusLift because the platform needs to ensure that only approved users can access the app.

To accomplish this, we implemented Google Sign-In.

This allows users to log into the application using their Google accounts instead of creating new usernames and passwords. Using Google authentication simplifies the login process while also providing a reliable identity verification system.

Google authentication is used to verify users during login.

Keeping Users Logged In

After implementing login functionality, the next step was making sure users do not have to sign in every time they open the app.

To solve this, we implemented Async Storage, which allows the application to store small pieces of data directly on the user's device.

Once a user logs in successfully, their session information is saved locally. This allows the app to recognize returning users and automatically keep them signed in.

Currently, user sessions are stored for seven days, after which the user will be asked to authenticate again.

await AsyncStorage.setItem( "@user", JSON.stringify({ ...data, savedAt: Date.now() }) );

This approach improves usability while still maintaining basic security.

Technologies Used

The current version of GusLift is being built using the following tools:

React Native (Expo) for cross-platform mobile development
Google Authentication for user login
Async Storage for storing session information locally

These tools allow us to rapidly prototype features while maintaining flexibility for future expansion.

What Comes Next

In the coming weeks, we plan to continue expanding the foundation of the app.

Some of the next steps include:

Improving how user sessions are handled within the application
Expanding support across multiple platforms
Beginning development of the core ride-sharing functionality

One of the long-term goals for the project is to make GusLift available across iOS, Android, and web platforms, allowing users to access the system from different devices.

Final Thoughts

GusLift is still in the early stages of development, but the core authentication system now provides a starting point for building the rest of the platform.

As development continues, the focus will shift toward building the features that actually enable users to request and offer rides.

Future posts will document the progress of the project as we continue building and testing new components of the system.