munstiBack home

Privacy for site and app

Your data, clearly.

This notice covers the gomunsti.com website and waitlist, and the goMunsti mobile app. It describes what the current implementation does with information and the choices available to you.

Website and waitlist

This launch waitlist collects one thing: your email address, with your consent, so we can tell you when munsti is ready.

What happens when you join

The waitlist will be operated through Sender, an email service provider. Sender’s double opt-in confirmation helps us verify that the address belongs to you. We will not ask for your name, location, ride data, or account details on this form.

When the waitlist is open, this website embeds Sender’s public form and loads Sender’s form script. Sender receives the submitted email address and operates the confirmation and unsubscribe flow. Sender may also process information needed to serve its form under its own current terms and privacy information.

Control and deletion

Every launch email will include an unsubscribe link. You can also ask us to export or delete your waitlist record by emailing help@gomunsti.com. We will only keep the address for launch communication or as long as needed to honour suppression requests.

Before signups open

The form is intentionally unavailable until the captain provides the public Sender form. No email is collected by this website while that configuration is missing.

What the mobile app handles

Account information. If you choose sign-in, the app uses Google or, on iOS, Apple through Supabase Auth. The account record can include your provider identity, email address, display name, and a Supabase account identifier. The app does not receive your provider password. Native sign-in sessions are stored in the device keychain or keystore.

Routes and rides. When you import a GPX file, the app processes its route name and filename, route geometry, timestamps, elevation and route summary on the device. While recording, it can store GPS track points, timestamps, altitude, speed, accuracy, distance, elapsed and moving time, and route progress. These records are used to show and record your ride, calculate ride metrics, provide route guidance, and let you export a GPX file.

Optional heart-rate data. If you choose a compatible Bluetooth LE heart-rate monitor, the app reads heart-rate samples for the ride. It retains a local reconnect alias and a one-way hash of the monitor identifier. The raw Bluetooth identifier is not uploaded. The heart-rate samples can be included in account ride sync.

Settings and technical state. The app stores settings such as units and the optional start/end map-trimming preference locally. It also stores pending sync batches locally so an interrupted upload can be retried. The current mobile app code has no separate advertising, analytics, or crash-reporting SDK.

Local storage and account sync

Guest riding works without an account. Guest route files, imported route data, ride history, and heart-rate data remain on the device. The guest flow retains at most one completed ride locally; starting another ride can replace the retained ride after confirmation.

On a signed-in account, the app can sync the normalized route geometry and summary, ride summary, recorded track points, and heart-rate samples to Supabase. A signed-in rider can also explicitly save a route to the account route library; that sync contains its route geometry and summary. The current sync code does not upload the original GPX bytes, filename, or local file path. Supabase application records are scoped to the signed-in account with row-level access policies.

Local route files and ride records are stored in the app’s private storage and SQLite database. Native sign-in sessions use the platform keychain or keystore. On the web build, Supabase uses the browser’s normal session storage instead.

Service providers and sharing

The current implementation sends or exposes information to these providers and recipients for the purposes described above:

The current app has no implemented social-sharing feed or advertising integration. It does not sync a guest ride to an account unless you sign in and the ride is then migrated to that account’s sync queue.

Permissions and your controls

The app asks for location access when you start recording. A ride started in the foreground can continue while the app is backgrounded or the screen is locked. The app does not request “Always” location access. iOS shows its location indicator; Android uses a visible foreground-service notification, and Android 13 or later may ask for notification permission when a ride starts. Denying location prevents recording that ride.

Bluetooth access is requested only when you scan for a heart-rate monitor. You can continue without a sensor, forget the remembered sensor, or deny Bluetooth access. The app does not request photo-library, camera, Apple Health, or Android Health Connect access in the current implementation. GPX import uses the operating system’s document picker.

On the Before You Ride / Devices screen, you can forget a remembered sensor. In Settings you can sign out, export completed rides, delete completed rides from the phone, and turn on display trimming for the start and end of a ride. Display trimming changes only the drawn line; it does not delete the underlying ride data. Signing out removes the local session and keeps local rides on the phone. Rides already synced remain in the account, and pending sync data can resume if you sign in again.

Retention and deletion

The app has no fixed automatic deletion period for local or synchronized ride data. The in-app Delete my rides control removes completed rides from the phone’s ride history, but it does not delete the account, synchronized copies, every other local route file, or local sync-queue batches already created for signed-in or previously signed-in rides. Those batches can contain route and ride details, track points, and heart-rate samples. A pending batch can still upload when you sign in to that account again and sync resumes, and completed batches also remain in the local queue. The app currently has no in-app account-deletion control.

To ask about access, correction, or deletion of account data, contact help@gomunsti.com. We do not promise a particular response time or a specific deletion result for copies held by third-party providers. Please include enough information for us to identify the relevant request, but do not send a password or sign-in token.

Security and limits

Native session tokens are kept in the platform keychain or keystore, and Supabase row-level policies are used to keep synchronized application records account-scoped. No method of storage or transmission is completely risk-free. Device access, operating-system backups, provider systems, and recipients selected through the share sheet are outside the protections munsti can directly control.

Children and processing locations

The current app has no age verification or child-specific account flow. This notice makes no numeric minimum-age claim. If a parent or guardian believes a child has submitted personal data, please contact help@gomunsti.com.

The project sources do not specify a hosting or processing region for Supabase, Sender, Google, Apple, or OpenFreeMap. This notice therefore makes no region or cross-border transfer claim. Those providers’ current notices and terms may contain further information.

Updates and contact

We may update this notice when the website or app changes. The effective date is shown below. For privacy questions or requests, contact:

Fabian Fleige
c/o IP-Management #10083
Ludwig-Erhard-Straße 18
20459 Hamburg, Germany
help@gomunsti.com

More provider and operator information is available in the Imprint.

Effective and last updated: 2 September 2026