Privacy Policy

Version 3.2 · effective 2026-08-01 · in force

This Privacy Policy explains what personal data RunMyB processes, why, with whom it is shared, and the rights you have. It applies to the RunMyB platform and console. The processing RunMyB performs on a customer's behalf is governed by the Data Processing Addendum; the console's cookies are described in the Cookie & Tracker Notice.

1. Who is the controller

RunMyB, Inc., a Delaware corporation ("RunMyB", "we"), operates the platform and is the data controller for the platform's own data about you: your account and login identity, your billing and credit-ledger records, your legal-acceptance records, and the platform's security and operational data.

Two processor relationships sit beside that controllership, and both are governed by the Data Processing Addendum:

• for the personal data that your applications process about their end-users, you (or your own client) are the controller and RunMyB is your processor;
• for the team-workspace data a customer manages about its members, the customer is the controller and RunMyB is the customer's processor (Section 3).

Contact for anything in this Policy: privacy@runmyb.com.

2. What we process, why, and on what basis

• Account and identity (your login identity, your principal) — to operate your account (contract).
• Ventures, products, documents, and your own conversation turns — to provide the service you asked for (contract).
• Billing and credit ledger — to charge you, keep credits, and meet accounting obligations (contract and legal obligation).
• Usage-metering records — what paid features you used, when, and the derived charges (contract and legal obligation).
• Connection records — for third-party services you connect: the provider, the label you gave the connection, your access tokens encrypted at rest, and the bindings that say which product or venture uses the connection (contract; the data flows themselves are described in Section 5.2).
• Operational logs and events — to run, secure, and debug the platform (legitimate interest).
• Aggregate product statistics (per-app request, pageview, and traffic counts) — derived from the platform's own server-side edge logs and from a cookieless first-party beacon in hosted product pages, and computed as aggregates only; raw visitor identifiers are never persisted, so no tracking consent is sought for them (legitimate interest — understanding whether and how the platform's hosted products are used; RunMyB's controller role for this processing is stated in Section 4).
• Correspondence — e-mail you send to the platform's contact addresses (legitimate interest, and contract or legal obligation where it concerns your account or a legal claim).
• Pre-launch waitlist signups — your e-mail address and the version identifier of the consent wording you agreed to, collected when you join the waitlist on runmyb.com (consent; the full description, including what is deliberately not stored, is Section 2.1).

2.1 The pre-launch waitlist

Before the platform opens publicly, runmyb.com offers a waitlist form. If you join it, the record we keep is:

• your e-mail address, normalized to lowercase — a repeat submission changes nothing and is never distinguishable from a first one;
• the version identifier of the consent wording you agreed to, stored verbatim as the evidence of your consent (see below);
• a short source token naming which page carried the form, the time of your signup, and — if and when we invite you — the time of the invitation and an internal identifier linking the record to the account the invitation created.

That is the whole record. We deliberately store no IP address, no browser or device information, no name, and no free text with a waitlist signup; the checkbox state itself is checked and then discarded, never stored.

Purpose. We use your address for one purpose: corresponding with you about access to the RunMyB beta. Because access is granted by hand, one person at a time, that correspondence includes the questions we need to ask before deciding — for example what you would build, who it is for, and how you would reach them. We do not promise to write, we do not promise access, and we make no statement about when, whether, or in what order invitations happen. We send no newsletter and no marketing mail to this address, we do not sell it, and it is not shared beyond the infrastructure on which the platform runs (Section 5.1).

Legal basis: consent (Article 6(1)(a) GDPR), given by ticking the unticked checkbox beside the form. The evidence of your consent is the stored version identifier together with the signup time; the exact wording each identifier refers to is preserved in this section, so what you agreed to remains recoverable for as long as the record exists. You may withdraw consent at any time by writing to privacy@runmyb.com; withdrawal does not affect the lawfulness of processing before it.

The consent wording, preserved verbatim. Version waitlist-privacy-v1 of the consent wording is:

Email me about access to the RunMyB beta, including any questions we need to ask before deciding. RunMyB, Inc. will use your address for that and nothing else, and you can withdraw any time at privacy@runmyb.com. Privacy Policy

("Privacy Policy" is rendered on the form as a link to this document.) If the wording ever changes, the version identifier changes with it and this section keeps every wording it has carried.

Retention. We keep a waitlist record until you are invited — the record is then the invitation's provenance and follows the life of the account it led to — or until you ask to come off the list, whichever comes first.

Your rights. A waitlist signup has no account and therefore no in-platform data-request flow; the route for access to, correction of, a copy of, or erasure of a waitlist record is privacy@runmyb.com, handled by hand within the statutory response period. If you have not been invited, an erasure request deletes the record; after an invitation, the record follows the account, and the account's own rights machinery (Section 9) covers it.

3. Team members

Where a customer's account has more than one user, the additional users (members — typically the customer's employees or contractors) are data subjects in their own right, and two relationships coexist:

• For the platform's own records about you personally — your acceptance records for these documents, your login identity, and the platform's security and operational logs — RunMyB is the controller, as for any user.
• For the team-workspace data the customer manages about you — your membership and role, your invitation, your per-member environment, your attribution in shared work — the customer is the controller and RunMyB is the customer's processor: the customer's administrators decide who is admitted, what role they hold, and when access ends, and the platform processes accordingly. This processor relationship is described in the Data Processing Addendum.

3.1 What member personal data we process, why, and on what basis

• Membership record — your role (administrator/member), status, display name, who invited you, and timestamps — to operate the customer's team account on its instructions (contract with the customer, processed under Article 28 GDPR; for the platform's own administration of access, legitimate interest).
• Invitation records — the invited e-mail address, the inviting administrator, the role offered, and expiry. Before you accept, the invited address is third-party personal data (you have no account yet): we process it on the legitimate interest of the customer in admitting you and ours in operating the invitation mechanism. On the administrator's instruction, the platform itself e-mails the invited address the acceptance link; that e-mail names who invited you, into which team, and that the invitation is to join them on RunMyB, and it states that nothing happens if you ignore it — the invitation e-mail is itself the first notice you receive about this processing. Invitation tokens are stored only as a cryptographic hash (the raw token is shown once to the inviting administrator and never stored); an invitation is valid for the period stated in the invitation itself, and expired or revoked invitation records are purged after a short, fixed period — an address that never accepts does not linger.
• Your per-member environment — your console arrangement, preferences, pins, and working context, remembered for you across machines — to provide the personalised service (contract).
• Attribution in shared records — your authorship of turns in shared venture conversations and your recorded decisions — for accountability within the customer's team and the integrity of the customer's records (legitimate interest of the customer and the platform; these attributions live inside the customer's records, Section 3.3).
• Venture assignments — which of the customer's ventures you work on — to organise the workspace (contract / the customer's instruction).
• Member-to-member messages — the messages you exchange with other members inside the account's workspace (contract / the customer's instruction; the export posture is in Section 3.2).
• Your acceptance records — which document versions you personally accepted, when, and from where — kept as append-only compliance evidence (legal obligation and legitimate interest in proving consent).

3.2 Your rights as a member — the self-export

Every member has the data-subject rights in Section 9 personally. In addition, you can export your own data — your acceptance records, membership record, environment and preferences, venture assignments, your messages, and the conversations you own — yourself, without an administrator's involvement, and download the bundle you filed for. In the messages you sent, the other party's read and delivery markers are redacted: your export does not reveal when someone else received or read your message. Account-wide requests are the customer's: a tenant-wide export or the deletion of the whole account is an administrator-only act (it concerns every member's and the customer's data at once).

3.3 Shared conversations are the customer's records

Your authored turns in shared venture conversations are part of the customer's records (see the Terms of Service & Acceptable Use, Teams — "Work products and shared records belong to the customer"). Your self-export therefore covers the conversations you own — your private lanes — and excludes shared venture lanes; the exclusion is reported in the export, with counts, never silently. Access to your personal data inside the customer's shared records is exercised through the customer, as is usual between employer and employee.

3.4 When you leave — the departed-member posture

When an administrator disables your membership, your access ends but the account's records do not change:

• Your personal lanes and preferences are retained under the customer's account but are inaccessible — nobody else gains access to your private assistant conversations by your departure; they simply stop being reachable.
• Your contributions to shared work remain, attributed, as the customer's records (Article 17(3) GDPR and the employment-records reality; retention follows Section 8).
• Erasure of a departed member's data narrower than the whole account is exercised through the customer as controller: the departed member's data is retained inaccessible under the customer's account, with the account-wide erasure machinery and the retention schedule in Section 8 as the outer bound.
• Disabling is reversible; the customer may re-enable you. Your acceptance records are not affected by disablement (they are compliance evidence, kept append-only).

4. The statistics posture

Product statistics come from two first-party sources, both operated by RunMyB and both producing aggregates only:

• Server-side edge logs — request and traffic counts read from the platform's own load-balancer logs.
• A cookieless first-party beacon — a small script served with hosted product pages that reports the visited page's address, the referring page, and the fact of the visit to the platform's own collection endpoint on the same site. The beacon sets no cookies, uses no local storage, does no fingerprinting, and performs no cross-site tracking — it reads nothing from your device beyond the page context it runs in, and a hosted product can switch it off entirely.

To count unique visitors without retaining identity, the collection endpoint derives a daily-salted, keyed hash server-side from the visitor's network address and browser signature and discards the raw values immediately — they are never logged and never stored. The salt changes every day, so the hash cannot link the same visitor across days; what is retained is only bucketed, aggregate counts. We do not set tracking cookies, we do not build cross-site profiles, and we do not retain raw per-visitor identifiers. This strictly-aggregate, first-party audience measurement follows the exemption the French CNIL articulates for such analytics, and it is why the platform needs no cookie-consent banner; the strictly-necessary session cookies the console itself uses are described in the Cookie & Tracker Notice.

Whose processing this is, stated plainly. For the aggregate product statistics — including those derived from visits to a customer's hosted product pages — RunMyB acts as an independent controller, on the basis of its legitimate interest in understanding whether and how the platform's hosted products are used. This is RunMyB's own processing, not processing on the customer's instructions, which is why it is described here rather than in the Data Processing Addendum. The customer's lever over it is the per-product opt-out: a hosted product can switch the beacon off entirely, and the platform then derives no beacon statistics from that product's pages.

5. Recipients

5.1 Our sub-processors

We share personal data with a small, named set of providers engaged by RunMyB, each under the provider's standard data-protection terms:

The Data Processing Addendum contains the authoritative sub-processor list, the change-notice and objection mechanics, and the transfer safeguards.

5.2 Connected services you authorize

These recipients are your choice — they are not our sub-processors. When you connect a third-party service to your account, the platform transmits data to it at your direction, under your own account and authorization; your own contract and the provider's privacy terms govern that processing, and the provider acts for you, not for us. Data flows only for what you explicitly connect or bind. Disconnecting stops the flow, immediately deletes the stored token from our encrypted vault, and — where the provider offers a revocation endpoint — revokes the token upstream as well.

• Git providers (GitHub, GitLab, Bitbucket, or a self-hosted service). If you export, synchronise, or import a product repository, the platform transmits that product's code and its git metadata (commit contents, messages, and timestamps) to your provider — only for products you explicitly bind to a connection. To operate the connection we store the provider's name and base URL, the label you gave it, and your access token, encrypted at rest through a write-only field: never shown back, never logged, never placed in command lines or URLs, used only at the moment of a git operation, and deleted when you delete the connection. Secret-scan findings reported to you carry masked values only.
• Google Drive (import). For Drive access the connection requests only the drive.file scope — Google's narrowest Drive scope, alongside basic identity (your e-mail address, to label the connection): access is limited to the individual files you explicitly pick in the Google Picker, never your whole Drive and never files you did not pick. A picked Google Docs file is exported to text and a regular file is downloaded as-is; the imported copy lives in your venture's document library with its provenance recorded, and we store only what you imported. Your Google tokens live only in the platform's encrypted vault, by reference — they never appear in logs, responses, prompts, or model transcripts — and your browser drives the Picker with its own short-lived token, distinct from the vaulted one.
• Gmail (where you connect it). The send scope only. The platform sends an e-mail through your account only after you have confirmed the exact message: assistants may draft, you confirm the precise payload, and the platform executes only what you confirmed, integrity-verified against what you saw.
• Google Calendar (where you connect it). Read-only event access; the platform periodically reads events of the calendar you connected.
• Trello. Your own Trello token; the platform periodically reads the boards and cards you connect.
• Notion. Your own Notion authorization (OAuth or an internal integration token you create); the platform reads pages and search results of the connected workspace.
• AI providers under your own keys. You may store your own AI-provider key (for example, an OpenRouter key) in the platform's encrypted vault and run your product's live AI features on it during previews: requests then flow to that provider under your key and your own relationship with it — distinct from the platform's own engine-lane use of OpenRouter listed in Section 5.1. Where your product offers its end-users their own keys, those keys belong to the end-user's own provider relationship and are stored encrypted for that purpose alone.

Imported content passes an automated content-safety admission before it enters the shared document library — the same category catalog the platform's build lanes use. An item flagged as needing review is held (not surfaced), with the reason recorded for a platform administrator; this is a security fail-safe applied at import time to content you chose to import, not an editorial review, and it operates within the human-review limits stated in Section 5.3.

5.3 Google user data — the Limited Use commitment

RunMyB's use and transfer to any other app of information received from Google APIs — including Google Workspace APIs — will adhere to the Google API Services User Data Policy, including the Limited Use requirements. In particular, for data received through your Google connections:

• No model training. Content obtained from your Google account is never used to create, train, or improve any machine-learning or artificial-intelligence model — RunMyB's or a third party's.
• No advertising and no sale. Google user data is never sold, never transferred to advertising platforms, data brokers, or information resellers, and never used to serve advertisements.
• No human review, except (a) with your affirmative agreement, (b) for security purposes such as investigating abuse, or (c) where required by law. Beyond the security-purpose admission hold described in Section 5.2, RunMyB operates no human-review pipeline over your Google data.
• Onward transfers only as necessary to provide the features you requested, for security, or to comply with law.

6. Voice dictation

The console's composer offers optional voice dictation. It is off unless you use it: nothing is captured or transmitted until you start dictation, and it stops when you stop it or the session ends. When you dictate:

• your microphone audio is streamed to Google LLC (the Gemini API) for transcription and, where you select it, translation. Google processes it as our sub-processor (Section 5.1): the relay runs under RunMyB's own key, that key never reaches your browser, and the audio travels only through the platform's enforced relay to Google's API endpoint;
• the platform does not keep your audio. What remains after a session is the transcribed text in your composer — it becomes part of your conversation records only if you send it — and a usage-metering record (the session's duration and the derived charge) kept for billing;
• we do not use your voice audio to train any model, and we send it to Google solely to provide the transcription you requested;
• usage limits apply and are enforced in-product.

7. International transfers

Some recipients process personal data in the United States. For personal data subject to the GDPR, the UK GDPR, or the Swiss FADP, transfers are protected as follows:

• Transfers to AWS, Stripe, Cloudflare, and Google rest on those providers' certifications under the EU–US Data Privacy Framework (with its UK and Swiss extensions), with the Standard Contractual Clauses in each provider's terms as the contractual fallback.
• Transfers to Anthropic, OpenRouter, Neon, and Zoho rest on the 2021 EU Standard Contractual Clauses (with the UK Addendum and Swiss amendments where those regimes apply) incorporated in those providers' data-protection terms. (Neon hosts each hosted product's database in a US region; Zoho hosts the platform's mailboxes in an EU data centre and the Clauses cover any extra-EEA access.)
• Where RunMyB processes personal data on your behalf, the Standard Contractual Clauses, Modules Two and Three, are incorporated through the Data Processing Addendum.

Data you send to a connected service under your own authorization (Section 5.2) is transferred under your own relationship with that provider, governed by its terms.

8. Retention

We keep personal data only as long as needed for its purpose, then delete or pseudonymise it. The criteria that determine the period, per category:

• Account, workspace, and content data — kept for the life of the account; on account deletion it is erased through the tiered erasure described in Section 9, subject only to the legal-retention carve-outs below.
• Billing, ledger, and acceptance records — retained after account deletion for the statutory accounting and limitation periods that apply to the record (where Polish accounting law applies, the accounting retention period it fixes), in pseudonymised form where possible, then deleted.
• Security and operational logs — kept for a bounded operational window sized to the security and debugging purpose they serve, then deleted or aggregated.
• Waitlist records — kept until the signup is invited (the record then follows the life of the account the invitation led to) or until the subject asks to come off the list, whichever comes first (Section 2.1).
• Aggregate statistics — non-personal by construction (Section 4) and retained as aggregates.

The full, per-store retention schedule is maintained internally as the platform's data map, which also drives the erasure machinery (Section 9); the criteria above are the rules that schedule implements.

9. Your rights

You have the rights of access, rectification, erasure, restriction, portability, and objection, and the right not to be subject to solely-automated decisions with legal effect. To exercise them, use the in-platform data-request flow (the primary mechanism — it records your request and tracks it against the statutory 30-day response clock) or e-mail privacy@runmyb.com. Data exports are produced as complete, structured bundles you download yourself; a team member can additionally self-export the data held about them personally (Section 3.2). Erasure is a tiered operation: content is hard-deleted, while the narrow set of records the law requires us to keep (billing, ledger, and acceptance evidence) is pseudonymised and retained for the legally required window, then deleted.

Automated checks, disclosed. The platform runs automated safety checks: every build request is screened against the content-safety taxonomy (the "Platform Rules — Content-Safety Taxonomy") before any app is built, and imported content passes an automated admission check that can hold an item from the shared library pending review. A hold routes to human review — it is a fail-safe, not a final decision — and you may contest safety decisions through the appeal route in the Terms of Service & Acceptable Use, Section 7.

10. Complaints

If you believe your data is processed unlawfully, you may lodge a complaint with the Polish data protection authority, the President of the Personal Data Protection Office (UODO), ul. Stawki 2, 00-193 Warsaw, or with your local supervisory authority.

11. US residents

We do not sell personal data, and we do not share it for cross-context behavioural advertising, as those terms are defined in US state privacy laws (including the California Consumer Privacy Act as amended). Stated honestly: RunMyB currently falls below the applicability thresholds of those laws, so most of their specific mechanics do not yet apply to it — but the no-sale, no-share posture is our commitment regardless of thresholds, and if the platform grows into those laws' scope, this Policy will be updated with the notices and rights they require.

12. Changes

This Policy evolves with the platform, under the same change process as the Terms of Service & Acceptable Use: a material change requires your renewed acceptance before you continue using the console; a non-material change takes effect on posting, with the version number, effective date, and changelog as the notice, and you are invited to review them. Every version is dated, versioned, and kept in the changelog.