Add a Riding Buddy

A rider sends a buddy request to another rider to establish a mutual connection.

Who Can Do This

Any user with status: active (free or subscriber).

Steps

Send an Initial Request

User finds another rider through one of these entry points:
The full participant list of a ride — only visible after the user has RSVPed YES or MAYBE.
The Buddies section in their profile, where they can search for a rider by email or phone number. This search only returns results when both the searcher and the result are in the same city. A user's city is set during onboarding or updated explicitly with GPS verification. See Update Profile.
User taps Add Buddy to send a request.
The recipient receives the buddy request and can accept or decline it.
If accepted, both users are added to each other's buddy list.

Resend a Request

Declined and expired requests remain visible in the sender's request history.

User opens their sent buddy requests screen.
A declined or expired request shows two actions:
Resend — available only if the sender has resend slots remaining (fewer than 3 total requests sent to that recipient). Tapping it sends a new request; one slot is consumed.
Delete — removes the record from the sender's history without consuming a slot. Available at any time, including after the resend limit is reached.
The recipient receives a push notification if a resend is sent.

Rules

Searching for a rider by email or phone number only returns a match when both users have the same city set. A user with no city set gets no search results until they set one. See Update Profile.
Buddy search is rate-limited to 20 searches per hour and 50 searches per day per user. Searches that exceed the limit return an error asking the user to try again later.
Buddy requests can only be sent to users who are not already the sender's buddy. A request can only be sent if all of the following are true:
The two users are not already buddies.
No pending request exists between the two users (in either direction).
The sender's request cap to the recipient is above 0.
When a user removes a buddy, the removed user's request cap to the remover is set to 0. This is permanent and overrides any remaining slots in the 3-request lifetime cap — the removed user can never send a buddy request to the remover again. The remover can still send a new request to the removed user. This block is not affected by any subsequent ban or unban of either user. A 95octane operator can reset this cap in edge cases (e.g. accidental removal or a support request). There is no in-app path for the removed user to request a reset — they must contact support. The practical self-service path is for the remover to re-initiate the connection by sending a new buddy request themselves.
Buddy requests expire after 30 days. Once expired, the request is no longer visible to the recipient. It remains in the sender's history until the sender deletes it.
Declined requests are removed from the recipient's view immediately. They remain in the sender's history (marked declined) until they expire or the sender deletes them.
The sender can cancel a pending request at any time before it expires.
City changes do not affect pending buddy requests — they remain valid regardless of either user's city after the request was sent.
There is no limit on the number of buddies a user can have.
A user can have at most 10 outgoing pending requests at any time. A new request cannot be sent until the count drops below 10. This cap applies to resends as well — a resend is blocked if the sender already has 10 outgoing pending requests, regardless of remaining resend slots for that recipient.
A user can send at most 3 requests in total to the same recipient (1 initial + 2 resends). A resend slot is consumed when a prior request is declined or expired. Cancelling a request does not consume a slot. After 3 total attempts, no further requests can be sent to that recipient.
The recipient receives a push notification when a request arrives.
The sender receives a push notification when the request is accepted. No notification is sent to the sender if the request is declined. Non-ban notifications are suppressed for banned users — if the sender becomes banned after sending a request, the acceptance notification is not delivered.
Buddy request caps (the 3-request lifetime cap and the removal-cap-of-0) are tied to the user's UID. If a user deletes their account and signs in again with the same Google or Apple account, the same Firebase UID is reused — all caps carry forward. From the product perspective the user goes through onboarding as a new account, but their prior cap state is preserved.
If the sender cancels a pending request, it disappears silently from the recipient's list — no notification is sent to the recipient.
Buddy features are independent of subscription and quota. Free users and subscribers can send and receive buddy requests without restriction.

What Happens Next

Once a buddy request is accepted:

Each user appears on the other's buddy list.
When viewing a ride's details before RSVPing, the user can see which of their buddies are already in that ride. Other participants appear as a count (e.g., "+4 riders").
After RSVPing to the ride, the full participant list is visible regardless of buddy status.
If a buddy removes the connection after the other user has already opened the ride detail page, the buddy preview updates on the next page refresh.

Failure Cases

Different city or no city set — searching by email or phone returns no results when either the searcher or the target is in a different city or has no city set. The search returns an empty result with no indication of whether a user exists at that address.
Banned or to-be-deleted user — banned users and users with a pending account deletion do not appear in search results. The search returns an empty result with no indication of whether a user exists at that address.
Request already pending — user cannot send a duplicate request while one is already awaiting a response.
Already buddies — user cannot send a request to an existing buddy.
Add Buddy unavailable — if the user viewing the profile was previously removed from that rider's buddy list, their request cap to that rider is 0. The Add Buddy button appears greyed out. Only the rider who removed them can re-initiate the connection.
Request expired — requests older than 30 days are automatically removed. A slot is consumed from the original sender's cap toward that recipient. The original sender may send a new request if they have remaining slots. The other user may also send a request in the opposite direction, subject to their own cap — unless they were previously removed by the other user, in which case the removal-cap-of-0 applies and only the remover can re-initiate.
Pending request cap reached — a user cannot send a new request while they already have 10 outgoing pending requests.
Resend limit reached — after 3 total requests to the same recipient (whether prior ones were declined or expired), no further requests can ever be sent to that recipient. This limit is permanent.
Active navigation session — the buddy list and Add Buddy flow are not accessible while a ride is in progress. The navigation screen is locked; the user must end the ride to access any other part of the app.

Planned — not yet live: The entire Buddy feature, including sending requests, accepting, and ride detail visibility, has not been built yet.