← OutTheGroupchat

Privacy Policy

OutTheGroupchat is a location-aware social product. That means this page matters more than most. It describes exactly what we store, who can see it, and how to make it stop.

Last updated: 2026-07-27

1. Who we are

OutTheGroupchat (“OTG”, “we”, “us”) operates a meetup-centric social network. You signal what you feel like doing, we group you with the people in your Crew who feel like doing the same thing, and you go do it.

Data controller: [LEGAL ENTITY NAME AND REGISTERED ADDRESS — TO BE CONFIRMED BY THE FOUNDER BEFORE PUBLIC BETA].

2. The two rules we build against

  • Location visibility is opt-in and per-decision, never a global switch you forget you flipped. The default for a heatmap contribution is “nobody”.
  • Your precise coordinates never reach another user. Location that feeds a heatmap is rounded to a cell centre before it is stored, and only the rounded cell is ever read back.

3. The three-axis location model

When you commit to a plan, you choose how visible that moment is along three independent axes. You choose per relationship and per event — not once, globally.

Axis 1 — social scope (who). Chosen for the specific plan:

  • Full Crew — every person you have an accepted Crew connection with can see the contribution.
  • Subgroup only — only the people in that specific sub-crew.
  • Nobody (the default) — you go out, and nothing is written to any heatmap at all.

Axis 2 — spatial granularity (how precisely). Set per Crew member at Privacy settings:

  • Block radius — the baseline for everyone. Roughly “which block”, not “which table”.
  • Dynamic cell — a finer cell. Opt-in, per person, never a default.
  • Hidden — that person sees nothing from you, ever.

Axis 3 — identity mode (whose). Also per relationship:

  • Known — the contribution is attributed to you by name. This is the default for direct Crew, because a Crew connection is already a two-way, explicit opt-in.
  • Anonymous — the contribution adds to density with no name attached, subject to the anonymity floor in section 4.
  • Crew-anchored — used for friend-of-friend viewers. They see “someone in [your mutual Crew member]’s circle”, never your name.

Choosing “nobody” for social scope short-circuits the other two axes: there is no contribution, so there is nothing to reveal at any precision.

An honest caveat about the current build. The full three-axis picker runs on the intent-and-sub-crew path. The quick check-in path does not yet expose it: a check-in you mark Private writes no heatmap contribution at all, while Crew or Public writes one at block precision, attributed, visible to your Crew. If you want finer control over a check-in today, mark it Private.

4. What the heatmaps actually store

A heatmap contribution is a derived record. Each row holds: your user id, whether it came from an intent (“where people want to be”) or a check-in (“where people are”), the id of that source record, a rounded cell latitude and longitude, the precision of that cell, the topic and time window where relevant, the social scope and identity mode you chose, and an expiry timestamp.

It does not hold your raw GPS fix. Coordinates are rounded to the cell centre at write time, and the raw value is never persisted on the contribution record.

Aggregation and the anonymity floor. Heatmaps are rendered from aggregated per-cell counts, never from a list of people. On top of that, a cell needs at least three anonymous contributors before its anonymous bucket is shown at all. Below three, that bucket is suppressed entirely, so “anonymous” cannot be trivially de-anonymised by being the only person in it.

Friend-of-friend layers work on connections computed at read time from accepted Crew edges. We do not store a second-degree social graph.

5. What a check-in records

A check-in stores: the venue (or free-text venue name) and city, an optional note you write, the visibility you chose (public, Crew or private), an “active until” timestamp that defaults to six hours from creation, an optional latitude and longitude, and the time you created it.

Who sees it follows the visibility you picked. Private check-ins are yours alone and contribute nothing to any heatmap. Crewcheck-ins are visible to people you have an accepted Crew connection with. Public check-ins are visible more broadly inside the product. Blocked users never see your check-ins regardless of visibility.

Check-ins stop being shown once their “active until” time passes. You can also delete one yourself at any time.

6. Categories of data we collect

  • Account and profile — email address, a hashed password if you use password sign-in (we never store the password itself), display name, avatar image, bio, home city, optional phone number, your label for your Crew, account creation and last-active timestamps, whether you completed onboarding, and your saved preferences including default check-in visibility.
  • Intents — the topic you picked, the time window, any custom start and end times, how many days ahead you signalled, whether you are interested or committed, an optional neighbourhood, an optional specific venue, and the free-text phrasing you originally typed.
  • Crew graph — your Crew connections and their status (pending or accepted), who sent each request, your sub-crew memberships, and your per-relationship privacy settings.
  • Check-ins — as described in section 5.
  • Location contributions — the rounded-cell heatmap records described in section 4.
  • Meetups and participation — meetups you host or attend, RSVPs, invitations sent and received, polls and poll responses, and posts and comments you write in the feed.
  • Notification preferences — which of the three triggers you have enabled (daily prompt, per-member intent, group formation), the time you chose for the daily prompt, and the list of Crew members you flagged for per-member alerts.
  • Trust and safety records — users you block, and reports you file (target, reason, any details you write, and the review status).
  • Device, session and technical data — authentication sessions and, if you sign in through an identity provider, the tokens that provider issues; your IP address, used for rate limiting and abuse protection and for slowing repeated failed logins; and server logs and error reports.

7. How we use it

  • To run the core loop — matching your intents with your Crew’s and forming sub-crews.
  • To render the heatmaps you and your Crew have opted into.
  • To recommend venues for a topic and area.
  • To send the notifications and transactional emails you have enabled.
  • To keep the service safe and available — rate limiting, abuse prevention, and acting on reports.
  • To diagnose errors and fix bugs.

We do not sell your data. We do not run third-party advertising, and we do not build advertising profiles from your location.

8. Third parties that process data for us

These are the external services actually wired into the product today. Each one is used for the narrow purpose listed.

  • Vercel — application hosting, plus privacy-friendly aggregate web analytics, plus blob storage for profile photos when that credential is configured. Serving the app means Vercel processes request metadata including IP addresses.
  • Neon (PostgreSQL) — the managed database where everything described in section 6 is stored.
  • Upstash (Redis) — rate limiting. Stores short-lived counters keyed to your user id or IP address.
  • Resend — transactional email only: invitations, Crew requests and acceptances, meetup invites and RSVP confirmations, and account emails such as password reset. Your email address is shared with Resend to deliver these.
  • Pusher — real-time delivery of live updates when that integration is enabled for your environment. It carries event payloads, not stored history.
  • Google Places — venue search and venue metadata. When you search for a place, your search text and the area you are searching are sent to Google. Google’s own privacy terms apply to that request.
  • Sentry — error monitoring. Receives stack traces and request context when something breaks, which can incidentally include identifiers.

Authentication is handled in-app by NextAuth.js; sessions and linked accounts are stored in our own database rather than by a third-party identity vendor. If you sign in through an external provider, that provider is a processor for that step.

9. Retention

  • Intents expire two hours after the end of their time window and stop contributing to any heatmap immediately at expiry.
  • Check-ins stop being shown once their “active until” timestamp passes — six hours after creation by default.
  • Heatmap contributions carry an expiry inherited from their source record and are excluded from every read after it passes.
  • Account and profile data is kept for as long as your account exists.

Known gap, disclosed honestly: expiry today controls what is shown. We do not yet run a scheduled job that hard-deletes expired intent and heatmap rows from the database; they are removed when you delete your account. Adding automatic purging of expired location contributions is on the list before the public beta.

10. Your rights, and how to actually use them

  • Change what you share. Default check-in visibility lives at Privacy settings; per-Crew-member precision and name visibility at Who sees your location; notification triggers at Notification settings.
  • Delete your account and everything in it. Go to Account settings and use the danger zone. You must type the word DELETE to confirm, so an accidental tap cannot wipe your account.
  • Access, correction and portability. Profile fields are editable in settings. We do not yet offer a self-serve data export — email us and we will produce your data manually.

What deletion actually removes. Deleting your account runs as a single database transaction. It removes your user record and everything that cascades from it: your sessions and linked accounts, your Crew connections, your intents, your entire heatmap contribution history — every location record we hold for you, your check-ins, meetups you host, invites you sent or received, your sub-crew memberships, your per-relationship privacy settings, your notifications and notification preferences, your blocks, your reports, your polls and responses, and your posts and comments. It is permanent and it is not recoverable.

Content that other people created is not deleted — for example, a meetup someone else hosted still exists after you leave it. Aggregate cell counts that no longer identify anyone may persist in derived form.

11. Security

Passwords are stored only as bcrypt hashes. Sessions are signed and expire after thirty days. Repeated failed logins are progressively slowed. All state-changing requests are origin-checked to prevent cross-site request forgery, every API input is schema-validated, user-written content is sanitised before display, and every endpoint is rate limited.

No system is perfectly secure. If you find a vulnerability, please report it to us before disclosing it publicly.

12. Age

OutTheGroupchat is for adults. You must be at least 18 to use it. We do not knowingly collect data from anyone under 18; if we learn we have, we delete the account.

13. Changes to this policy

If we change what we collect or who we share it with, we will update the date at the top of this page and, for material changes to the location model, tell you in the app before the change takes effect.

14. Contact

Privacy questions, data requests and vulnerability reports: privacy@outthegroupchat.com (placeholder address — to be confirmed by the founder before public beta).