1. Who this notice is about
BlockBite B.V. is the controller for operating the participant accounts, access, support and evaluation service in this invited business rehearsal. It runs through 23:59 on 15 November 2026, Europe/Amsterdam. Contact us at hello@block-bite.com.
Only invited adults acting professionally may participate. Use fictional project, client, invoice and end-user content. Real participants still use their own sign-in identities, and their account details, invitations, comments and support messages can be personal data. The fictional-data restriction does not make those records anonymous.
An inviting business is responsible for its choice to disclose a colleague’s or participant’s contact details and should invite only expected participants. This offer does not include processing production client personal data on an agency’s instructions. The actual responsibilities and any required processing agreement must be settled before such a use starts. Independently chosen website hosting, repository and AI accounts have their own arrangements.
2. Information we receive
- Accounts and security: your name and email, a password hash if you choose password signup, email-verification and recovery records, provider identifiers and email for an enabled GitHub/Google sign-in connection, and security/session information. Optional two-factor authentication has its own protected setup and recovery information.
- Legal review: the Terms and Privacy versions and server-recorded acceptance/review times. Test subscription checkout keeps a separate record of the offer and its confirmation.
- Projects and collaboration: account/project identifiers and names, repository references, membership and project permissions, invitations, selected review content and assets, comments, discussions and related notification state. What is shared depends on the function you use and its current access settings.
- Invitations from others: an inviter can provide your email or GitHub handle. Matching a GitHub invitation can also involve public profile identifiers. The invitation and later verified sign-in information come from those sources rather than solely from a form you fill in yourself.
- Test billing and optional invoice connections: provider account/customer, checkout, subscription and event identifiers and relevant status/offer information. An agency’s invoice connection can read customer and invoice data from its selected Stripe account for authorised display and linking.
- Service operation and support: request/session information such as IP address and browser details, request time and route, relevant error/incident records and information you provide when asking for help. Do not include project secrets or other people’s information in diagnostics.
Do not enter real payment details or real client/end-user personal data, sensitive test material or credentials into rehearsal content. Provide only information you are authorised to use.
3. Local work and selected external operations
Desktop opens the project folders you select. Editing a local Astro project does not automatically create a hosted backup of all its source files. Local project files and application preferences are distinct from material you deliberately submit for hosted collaboration.
Repository publishing and external AI are optional operations you choose separately. When you push changes, publish through your hosting workflow or start an AI operation, relevant content and context can be sent to the provider accounts involved. AI requests can include messages, selected project context and authorised tool results. Review these before sending and use fictional material without participant identifiers or secrets. Choosing an integration does not by itself establish consent as the legal ground for every provider’s processing.
Desktop uses operating-system-backed protection for credentials held by its protected storage features. Platform’s login connection stores a provider identity/email rather than retaining login-provider access tokens as a durable account connection. Other integrations, such as the invoice App, require separate provider grants held on Platform.
4. Purposes and grounds for this rehearsal
The following purposes and grounds apply to the actual invited evaluation. They do not establish a ground for later public-beta, marketing or production-client processing.
| Purpose | Ground |
|---|---|
| Create and operate an account requested by an individual acting in their own professional capacity, including sign-in, recovery and requested test functions | Performance of that individual’s rehearsal agreement, where the processing is necessary for it. |
| Operate access, invitations, collaboration and transactional messages for an organisation’s contact people and invited participants | Legitimate interests of BlockBite, the inviting business and the expected participant in conducting this bounded business evaluation. We limit the data to the invitation, identity and access needed for it. An organisation’s contract is not treated as the individual contact person’s contract. |
| Secure accounts, prevent misuse, troubleshoot the rehearsal and handle related support | Legitimate interests in a secure, functioning evaluation and resolving reported problems, using only relevant records with limited access. |
| Record which Terms were agreed and which notice was reviewed, and handle a concrete legal claim | Legitimate interests in showing the agreement and resolving that claim, retaining only the information needed. |
| Respond to data-protection requests or a binding legal requirement | Compliance with the applicable legal obligation, limited to the request or requirement concerned. |
For these legitimate interests, we restrict the evaluation to expected business participants, fictional project material, necessary identity/access data and relevant security/support records. Project permissions limit disclosure, optional connections are separate choices, and you can object or request closure through our contact address.
The signup checkbox identifies the Terms and notice you reviewed. It is not blanket consent for every use of your data. If a separate optional activity relies on consent, its purpose and choice must be presented separately, and that consent can be withdrawn.
5. Who can receive information
Authorised project participants receive the selected information made available through project access, reviews and discussions. An account owner can manage project membership and permissions; joining a project does not itself give you access to the agency’s billing or unrelated projects.
| Operation | Recipient and information involved |
|---|---|
| Hosted account, session, project access and selected collaboration | Laravel Cloud hosts Platform and its database in Frankfurt; submitted assets use the selected private EU object-storage bucket. Account identifiers, access records and selected collaboration material are stored there. |
| Transactional account, security and invitation email | Brevo receives the recipient address and the message/link information needed to deliver it. Support email sent to our contact address also passes through the business mailbox provider. |
| Optional identity sign-in | GitHub, or Google if enabled, exchanges the identity/profile/email information needed for that sign-in. GitHub repository access requires a separate connection and permissions. |
| Simulated BlockBite subscription upgrade | Stripe test Checkout receives the account/contact and test checkout information needed for the selected offer. BlockBite retains provider identifiers, status and a separate confirmation record. |
| Optional agency invoice connection | The agency’s separately installed Stripe invoice App reads fictional customer/invoice data from its selected test account for authorised display and linking. Its grant is held encrypted on Platform. |
| Participant-selected repository, hosting or external AI operation | The provider chosen by the participant, such as GitHub, Vercel, OpenRouter or a connected ChatGPT client, receives the content/context needed for that chosen operation. Its account and data arrangements apply separately. |
Only authorised operators may use service data for support, security and operating this rehearsal. Provider roles depend on the actual operation and contract. The provider/account-specific contract register, including the business mailbox supplier and infrastructure/support recipients, is still being verified for this rehearsal. Ask hello@block-bite.com about the recipients for a particular operation.
6. Where data is processed
The rehearsal’s Platform compute/database region is Frankfurt and its selected private object bucket is in the EU. That does not establish that every connected provider or support operation keeps all data within the EEA.
The provider-specific countries, remote support access and applicable transfer arrangements have not yet been fully verified for this rehearsal. We do not claim that all processing stays in the EEA or that an EU hosting region establishes the arrangements for every supplier. Contact hello@block-bite.com for the current information about the operation you intend to use. The provider register must be completed before this text can describe those arrangements as verified.
7. Retention and deletion
BlockBite will use the following operator-run schedule for this short rehearsal. Cleanup is manual; an automated account-wide deletion feature has not been established. Temporary access expiry and scoped review cleanup do not themselves delete every account record.
| Category | Retention rule |
|---|---|
| Rehearsal account/profile, memberships, invitations, consent/review receipts, test-billing associations and hosted project/review/discussion material | Keep only for running and finishing the rehearsal, then delete from active BlockBite storage within 30 days of its end: by 15 December 2026, 23:59 Europe/Amsterdam. A justified earlier deletion request is handled without waiting for that date. |
| Sign-in sessions, temporary proofs and integration grants | End access and revoke grants as part of offboarding; clean up related stored records with the rehearsal records. A proof or cookie expiring is distinct from deleting its record. |
| Ordinary support correspondence | Remove within 30 days after the request is resolved, except a necessary record of a privacy request or unresolved dispute. |
| A documented security incident, privacy request or legal claim | Retain only necessary restricted records while it is being handled; review at resolution and remove within 90 days unless a specific legal obligation or continuing claim requires a different documented period. |
| Cloud/provider access logs, backup copies, mail delivery records and Stripe test-provider records | These records follow the relevant provider-specific retention and deletion arrangements; exact periods and capabilities are still being verified. These copies cannot be represented as deleted merely because an active Platform row was removed. |
| Files and records in your own local project or independently controlled provider account | You manage those copies and their removal, subject to the provider’s own terms. |
The exact Cloud log/backup, mail delivery and Stripe provider-record periods and deletion capabilities are still being verified. Deleting an active account is not a guarantee that every provider copy has immediately been erased. The active-storage schedule above is a manual BlockBite commitment; it does not set or guarantee every provider’s separate expiry.
Ask for closure or deletion at hello@block-bite.com. We will confirm the applicable action, records retained for a specific reason and relevant provider limits. Ending project access does not itself remove local files or independently controlled provider copies.
8. Cookies, local storage and required information
The hosted account uses session and form-security cookies. The current source default is a 120-minute session lifetime; that setting is not a database-record deletion period. The marketing site saves a blockbite-marketing-theme preference in browser local storage until you change or clear it. Desktop stores application/project preferences locally. Blocking required browser storage can prevent sign-in or other requested functions.
The rehearsal excludes advertising/tracking and optional analytics. Deployed cookie names, lifetimes, enabled diagnostics and provider open/click tracking settings still need confirmation against that restriction. We do not describe a targeted source check as a complete deployed storage or tracking audit.
Account identity information and the checks needed to verify it are required for hosted account access. Optional provider or AI connections need not be enabled to grant unrelated permissions. There is no marketing-signup consent bundled into the legal-review checkbox.
9. Your rights and contact
Subject to the conditions in applicable data-protection law, you can request access, correction, deletion or restriction of your personal data, and portability where it applies. You can object to processing based on legitimate interests, and withdraw a consent where a particular activity relies on it. These rights can have lawful limits.
Send a request to hello@block-bite.com. We may ask for proportionate information to confirm your identity. We will respond without undue delay and normally within one month. Where the law permits an extension or a limit on the request, we will explain the reason and available complaint/remedy routes within the applicable period. Requests are ordinarily handled free of charge. You can complain to the Autoriteit Persoonsgegevens or another competent supervisory authority.
The rehearsal uses no profiling or solely automated decisions producing legal or similarly significant effects. Account verification, current permissions and test-plan checks still control access automatically. Contact us if you believe a check has incorrectly blocked you.
10. Notice versions
The notice shown for an account action has a version so that your review can be identified. We will email material changes affecting participants before they take effect, except where an urgent legal or security need requires earlier action; then we will explain them as soon as practicable. Expanded processing needs an updated notice and any required separate choice before it starts.