Delete Account

A user permanently removes their account and all associated data from 95octane.

Important distinction: A user going through the deletion flow remains status: active until the moment they confirm deletion at the final step. The account is only set to to_be_deleted once every owned asset is resolved and the user explicitly confirms. Until that point, all normal platform rules (subscription, group freeze, ride rules, etc.) apply without exception. The deletion flow does not create a special intermediate state — it is simply a guided sequence of actions a user takes while still fully active.

Who Can Do This

Any user with status: active. Banned users can also delete their account — the option appears on the Ban screen alongside the appeal option.

Steps

  1. User initiates deletion from app settings. Before showing the asset list, the app runs blocking validations. If any fail, deletion cannot proceed:
  2. Active navigation session — the user must end the ride on any device before deletion can be initiated.
  3. Owned started ride — if the user owns a ride that is in on-going status (started by any participant and not yet formally completed), deletion is blocked. The block remains even if no participant is currently navigating, as participants may restart during the ride window. Once the ride formally completes, the user must restart the deletion flow from the beginning — it does not resume automatically. The same applies if a ride starts during the asset resolution step (step 2): the user must restart the entire deletion flow after the ride formally completes. 95octane currently supports single-day rides only, so the maximum block duration in this situation is 1 day.
  4. Pending outgoing transfer offers — if the user has already sent a transfer offer for any owned asset and it has not yet been accepted, deletion is blocked until the offer is accepted or cancelled. The user must resolve these outside the deletion flow before proceeding.
  5. Once all validations pass, the app shows all remaining assets to resolve: owned groups, owned rides (not yet started), and upcoming RSVPs. Any pending transfer offers the user has received (where they are the recipient, not the sender) are listed separately and will be automatically declined when deletion is confirmed — the senders are notified. The user must acknowledge this before proceeding. For each owned asset, the user must confirm deletion:
  6. Delete — asset is immediately deleted.
  7. Withdraw RSVP — for rides the user has RSVPed to but does not own.

If the user wants to transfer an owned asset instead of deleting it, they must exit the deletion flow, complete the transfer, wait for the recipient to accept, and then return to initiate deletion. 3. Once all assets are resolved, the app shows subscription cancellation instructions before proceeding. The user must explicitly acknowledge that they will cancel their subscription. If an email address is on file, the instructions are also sent by email at this point. The deletion cannot proceed until the user acknowledges. 4. User confirms deletion. Account is flagged to_be_deleted. User is signed out. 5. 7-day grace period. The user is not signed in during this period — opening the app shows only a deletion notice with a single option to cancel. No app features are accessible. All notifications — push and in-app — are suppressed for the duration of the grace period. Cancelling restores status: active and returns the user to the app normally. Admin roles are not restored. 6. After 7 days, the account is permanently deleted. Buddy relationships and pending buddy requests are removed at this point. User data is handled per the Data Retention Policy.

Banned users follow the same asset hand-off process. It is presented inline on the Ban screen before deletion is confirmed. Banned users can only delete their owned assets — ownership transfer is not available to them. The transfer option is not shown during the asset resolution step for banned users.

Visibility

The user is hidden from all lists, searches, ride views, and buddy lists immediately when to_be_deleted is set — not after the grace period ends. Their details are also hidden from ride history during the grace period — other riders see a placeholder instead of the user's name and photo. All underlying data — group memberships, buddy relationships, pending buddy requests, and pending group invites — is preserved during the grace period. If the user cancels deletion, they become visible again everywhere and all memberships and connections are fully restored. Data is only permanently removed at actual deletion after 7 days.

Subscriptions

The deletion flow always includes a subscription cancellation acknowledgment step (step 3 above). What the user sees depends on their situation:

  • Google Play subscriber (standard deletion): 95octane cannot cancel programmatically from the deletion flow. The user must cancel manually and acknowledge they have done so. If an email address is on file, the instructions are also sent by email.
  • Google Play subscriber (banned_final): The subscription was already cancelled via RevenueCat when the ban was made final. The acknowledgment step is still shown, but the UI indicates the subscription has already been cancelled — no manual action is needed.
  • Apple subscriber (any path): 95octane cannot cancel programmatically. The user must cancel manually and acknowledge they have done so.

Manual cancellation instructions (shown where applicable):

  • iOS: Settings → Apple ID → Subscriptions → 95octane → Cancel Subscription
  • Android (standard deletion): Google Play → Profile → Payments & subscriptions → Subscriptions → 95octane → Cancel

The acknowledgment is informational — 95octane has no way to verify or enforce that a manually cancelled subscription was actually cancelled. If the account is permanently deleted while an Apple subscription is still active, 95octane takes no further action. Billing continues through the store until the subscription naturally expires.

What Is Deleted

Permanent deletion removes:

  • The user's profile and all saved favorites.
  • The user's membership and admin role in every group they belong to.
  • The user from every other rider's buddy list, and all pending buddy requests sent or received. Outgoing buddy requests do not need to be resolved before deletion proceeds — they are preserved (but hidden) during the grace period and permanently removed at actual deletion.
  • All pending group invites the user received but had not yet acted on.
  • The user's identity from all completed rides. Participation records are permanently anonymised — the placeholder shown during the grace period becomes the permanent record.

Some data may be retained after deletion for legal and fraud-prevention purposes under GDPR Article 17(3)(e) and equivalent provisions of India's DPDPA. See the Data Retention Policy.

Rules

  • The account is not flagged to_be_deleted until every owned group and ride is deleted and all RSVPs are withdrawn. The 7-day grace period only begins after full resolution.
  • Frozen groups (from a lapsed subscription) must also be deleted before deletion can be confirmed. The freeze does not block deletion of the group itself during the asset resolution step.
  • Admin roles are not restored when a user cancels deletion during the grace period.

What Happens Next

After the grace period expires, all user data is permanently deleted per the Data Retention Policy. The Firebase Auth account is flagged as deleted — the sign-in providers and UID are preserved, not released.

If the user returns in the future using the same Google or Apple account:

  • The same Firebase UID is reused.
  • If the data retention period has passed and no retained data exists, a fresh Firestore profile is created — the user goes through onboarding as a new account.
  • If retained data still exists within the retention period, that data may be used to partially restore the profile, but the user is treated as a new account for all product purposes.
  • The 4-ride Premium quota does not reset. Quota is permanently tied to the Firebase UID. Deleting and recreating an account with the same provider does not restore quota — the UID is reused and the consumed quota carries over.

Failure Cases

  • Sign-in during grace period: User is notified their account is pending deletion and must explicitly choose to cancel or let it proceed.
  • Pending outgoing transfer offer: Deletion cannot be initiated while the user has an unresolved outgoing transfer offer. The user must cancel or wait for the offer to be accepted outside the deletion flow.

Status: partially-live. Backend DELETE /user/:id endpoint is complete. Frontend account deletion UI is not yet built.