Privacy Policy

The person responsible for processing personal data on the founderi platform within the meaning of the General Data Protection Regulation (GDPR) is:

ExpertsMedia LLC 30 N Gould St, Ste N Sheridan, WY 82801 USA

E-Mail: hello@founderi.io

This statement applies to founderi's publicly accessible pages, the web app, the Progressive Web App (PWA), user accounts, Communities, direct messages, voice and video rooms, stages and their recordings and transcripts, events, courses, the media library, the network and the feed, the assistant “Foundi”, the partner programme and the payouts, the ID check, publicly shared content, link pages and short links, support requests as well as the associated emails and push notifications.

You can address data-protection enquiries, requests to exercise your rights and questions about this statement to the address given above or to the contact details published in the legal notice. We have not appointed a data protection officer; under Art. 37 GDPR this is currently not mandatory for us.

We only process personal data to the extent that this is necessary for the provision of founderi, the implementation of the user agreement, the security of the platform, legal obligations or the function you have requested. We pay particular attention to data minimization, purpose limitation, integrity and confidentiality (Art. 5 GDPR).

Depending on use we process in particular master data (name, display name, username, email address), account and security data, profile and preference data, usage and communication data, content data and media, audio and video data from rooms and stages along with their transcripts, voluntary location details, device and connection data, payment, billing and commission data as well as — only when the respective feature is used — ID and identity data including biometric data.

The legal bases are: Art. 6(1)(b) GDPR for performance of the contract and pre-contractual measures; Art. 6(1)(c) GDPR for statutory retention, documentation and audit obligations; Art. 6(1)(f) GDPR for IT security, misuse prevention, error analysis, reach measurement and stable operation; Art. 6(1)(a) GDPR for voluntary consents as well as Art. 9(2)(a) GDPR for the explicit consent to a face match during the ID check.

We process biometric data for the unique identification of a person exclusively within the ID check (sections 20 and 21) and exclusively with your explicit consent. We do not deliberately collect other special categories of personal data under Art. 9 GDPR; if you voluntarily provide such details in your profile or in posts, you are manifestly making them public yourself (Art. 9(2)(e) GDPR).

founderi's production environment runs on Microsoft Azure. The application runs as an Azure Container App; the application database is an Azure Database for PostgreSQL Flexible Server; files are held in Azure Blob Storage; secrets are managed by Azure Key Vault. The production deployment is designed for the Azure region Germany West Central (Frankfurt). The AI resource is operated in an EU region (default: West Europe, Netherlands).

We run the servers for voice and video rooms (LiveKit) on infrastructure of Hetzner Online GmbH in Germany. They are the only part of the platform that does not run at Microsoft.

When the platform is accessed and with every API request, technically necessary log data arises: IP address, date and time, requested address and HTTP method, status code, amount of data transferred, referrer information, browser identifier as well as details on browser, operating system and device derived from it. For signed-in requests, log data may be linked to an account or session identifier, in so far as this is necessary for error analysis or misuse prevention.

We process this data in order to deliver content, detect attacks and misconfigurations, monitor availability and performance, investigate security incidents and protect the platform against unauthorised access. The legal basis is Art. 6(1)(f) GDPR. The logs are processed in Azure Monitor / Log Analytics and deleted there after 30 days. Only people with operational or security duties have access.

Accounts, memberships, Communities, channel structures, settings, permissions, interactions, messages, payment references and further data sets necessary for the platform to work are stored in the Azure PostgreSQL database. In the production architecture, the database and object storage are not generally reachable from the internet; access goes through the application and network infrastructure set up for it and via managed identities, not via access keys.

Files and media – such as profile pictures, banners, images, videos, documents, chat attachments, course material, voice messages, stage recordings, presentations, brand templates and support attachments – are stored in non-public containers of Azure Blob Storage. Content is not delivered via freely accessible storage addresses but only after an authorisation check by the platform. Accounting receipts, database backups, the founders' club documents and the images of an ongoing ID check are stored in logically separated areas, each with its own access check; for ID images there is no general delivery route at all (section 21).

When uploading, we process the file name, file type, size, technical metadata and the content of the file. Image metadata is cleaned where technically provided for, so that location data or device identifiers from a camera are not published along with it. Uploaded files are checked for malware and conspicuous file structures. The legal basis is Art. 6(1)(b) GDPR as well as our legitimate interest in a secure service under Art. 6(1)(f) GDPR.

A user account is required for protected areas. For registration and account management we process in particular the email address, name or display name, username, language, time zone, profile details, account identifier, the times of registration and last activity, the route by which you came to us (a referral link, for instance) and the settings you have chosen.

For signing in, founderi uses a one-time, time-limited code sent by email. We do not store plain-text passwords. To check, limit and secure the sign-in process, we process the code only in protected form, the associated email address, timestamps, session and device information as well as security-relevant events. In addition, protection with an authenticator app or device sign-in (passkey) can be set up. Addresses from disposable providers we reject at registration; for that we compare the domain of your address against a list of such providers.

You can connect several devices to the same account. For that we store per device an identifier, a label, the browser and operating-system class as well as the times of sign-in and last use, so that you can see your devices in the settings and sign them out individually. For two handovers between computer and phone – a profile picture from the phone gallery and continuing an identity check on the phone – we create a short-lived, single-use handover code; no sign-in takes place on the phone, and the process ends after the handover.

We use technically necessary session cookies and comparable storage mechanisms so that logged in people can be recognized, the session remains protected and security-relevant settings work. The legal basis for storage on your device is Section 25 Paragraph 2 No. 2 TDDDG; The subsequent data processing is based on Art. 6 Para. 1 lit. b and lit. f GDPR.

To secure your account we keep a sign-in history: for each sign-in the time, IP address, country and browser identifier. It answers the question whether someone else has signed in to your account. In addition we record once by which route you came to founderi — source channel, campaign markers of a link and the referring page; this row is created at registration and is not updated afterwards. The legal basis is Art. 6(1)(f) GDPR.

On the publicly accessible pages we run a reach measurement that works entirely without recognition. It is a tally kept on the server and condensed to the full hour: for each hour we count how many views fell on a particular combination of characteristics. Nothing is stored on or read from your device in the process – no cookie, no identifier, no tracking pixel; § 25 TDDDG therefore does not apply.

Counted per hour are: the pattern of the page opened (for instance “/tarife” or “/c/[slug]” – never the complete path, so never which individual Community someone looked at), the source channel and the campaign attributes of a link, the hostname of the referring page, the TYPE of a click identifier from an ad (not the identifier itself), the device class, the browser's base language, the country from the delivery network's header and whether the request came from a recognised search engine crawler.

These figures say how many people reach the pages and where they drop off – a question that cannot be answered with the data of signed-in accounts, because those accounts don't yet exist at that moment. Views by signed-in people are not counted here. The legal basis is our legitimate interest in a comprehensible reach and advertising evaluation under Art. 6(1)(f) GDPR. No link to a person arises in the process, nor is one established.

We use technically necessary cookies, local storage and comparable browser-side storage for sign-in, security state, language, font size and contrast, view mode, the PWA function, notification settings and reliable operation. Some of these settings deliberately belong to the device and not to the account – anyone who has to enlarge the text in order to read should be able to do so before signing in. The legal basis is § 25(2) no. 2 TDDDG in conjunction with Art. 6(1)(b) and (f) GDPR.

Beyond that we analyse the use of the platform – but exclusively in so far as you have consented to it. On the first visit after signing in we ask you about it; until you decide, we collect only what is necessary for operation and security. There are no pre-ticked boxes. You make your decision separately for three purposes: product improvement, personalisation and advertising. The legal basis for storage on your device is § 25(1) TDDDG, for the subsequent processing Art. 6(1)(a) GDPR.

If you have consented, we process usage events: views opened (as a route pattern, not as a complete address), dwell and reading time, scroll depth, interactions with posts, channels, media, short videos and courses, playback and swipe behaviour in the short-video reel, participation in events and stages, steps in the ordering process, a device and session identifier generated in the browser, device type, operating system, browser, language setting, time zone, country and a non-reversible hash of your IP address to prevent misuse. We do not record the contents of your messages, posts and search queries in this.

From these events we derive an interest and usage profile (for example topic interests, preferred device, time of day of use, frequency of use, purchase interest) and form target groups from it. Personalisation expressly includes two things you cannot see in a feed: it already responds within a single session to what you are reading right now, and it takes into account the behaviour of accounts with similar interests – so what is suggested to you does not depend on you alone. If you have consented to the purpose “advertising”, the profile serves to select and measure the success of advertising within founderi.

If the scope of these purposes changes, your earlier consent is considered outdated and we ask again. Consent once given does not silently extend to new processing.

We do not sell personal data. We do not pass your usage behaviour to advertising networks, use no social-media pixels and run no cross-device or cross-provider tracking beyond founderi. The selection of advertising happens on our own systems. No automated decision with legal effect or similarly significant impact within the meaning of Art. 22 GDPR is connected with this.

You can withdraw your consent at any time with effect for the future – in your profile under “Data and privacy”, with the same effort as when you gave it. On withdrawal we delete the derived profile and your audience memberships without delay; the underlying events are no longer used and are deleted in the next regular run. The lawfulness of the processing carried out up to the withdrawal remains unaffected.

Depending on the purpose, we store usage events for at most 90 days (product improvement) or 180 days (personalisation and advertising) and delete them automatically afterwards. We log your consent decisions so that we can demonstrate them under Art. 7(1) GDPR; this log is deleted along with your account.

If you use a Community, we process your membership, roles and permissions, channel and course assignments, posts, comments, reactions, mentions of people and Communities, polls and votes, direct messages, invitations, reports, moderation actions as well as time stamps and the recipient and visibility information required in each case. Visibility follows the access rights and roles set by the Community; roles always apply only inside the Community that granted them.

For the personal feed and the network functions we process connection requests, accepted or rejected connections, interests, interactions and the content you publish. If a Community uses Aktivitätspunkte, levels, leaderboards, daily quests or badges, we process your counted actions in that Community for this; which of these displays exist at all is decided by the respective moderation. The legal basis is Art. 6(1)(b) GDPR.

Your profile includes, besides name and picture, the details you enter there yourself: short description, headline, occupation, company, current project, place, website, interests, skills and a career history with position, organisation, place and period. All of these details are voluntary, changeable at any time and visible to the people allowed to see your profile — none of them is a prerequisite for core use.

In direct messages, both sides see when a message reached a device and when it was read. In channels we remember how far you have read, so that the unread dot is correct; which short videos you have opened we remember for the same reason. Anyone who reacted to a post or voted in a poll is identifiable within the Community to those entitled to see it.

We store blocking and muting as a link between two accounts. Both are a statement about another person and therefore exist only for their effect, not as information: the blocked person does not learn from us that they have been blocked or by whom. The legal basis is Art. 6(1)(b) GDPR.

Message texts, direct messages and transcripts are stored encrypted in the database. Encryption, however, does not replace an access decision: people to whom you make content available inside a Community or a direct message can, within their permissions, see it, save it or pass it on. Please therefore do not share data that other members are not meant to receive.

If you edit a sent message, the previous version is kept as history and the edit is visible to everyone involved; if you withdraw a message, the line remains as a placeholder because replies point to it. Content that has been reported remains accessible to moderation even if it is deleted or changed afterwards – otherwise every report could be invalidated simply by deleting.

You can hide your membership of a Community. Then you will not appear there in any member list, attendance list or leaderboard, and the Community will not show in your public profile. Your posts stay visible – whoever writes appears with their name underneath. The leadership of that Community and the founderi team continue to see the membership.

Community founders as well as administrators and moderators they appoint can – according to their roles – view and manage memberships, visible profile details, content inside their Community, moderation reports and Community statistics. They can invite members, assign roles, remove or editorially correct content, restrict access and set their own rules. These people act on behalf of the respective Community; founderi provides the technical platform.

Before joining, please check a Community's description, access rules and membership. Content in public areas or in areas released to a larger group of members can be seen by everyone authorised to do so. Direct messages are intended only for the conversation partners you have chosen; in the case of a report, or a legally permitted or security-related review, authorised platform bodies may be involved.

Insofar as those responsible for a Community independently determine purposes and means of processing member data outside the platform – for example for their own invitation lists, events or communication outside founderi – they are responsible for this themselves. This statement describes the processing by founderi and the functions provided within the platform.

For current messages, notifications and presence and room status, the platform keeps a permanent connection to the server (Server-Sent Events). Session identifier, connection time, technical connection data, online status and the event data needed for delivery are processed. In addition, we show that someone is currently in a conversation – measured by participation in a room, expressly without revealing which one. Anyone who has chosen “Show as offline” does not appear as present even then.

For voice rooms, stages, direct calls and video offerings we use WebRTC and LiveKit as media servers. Setup and connection data are processed (IP addresses, room and participant identifiers, timestamps, technical device and network parameters) as well as the audio and video data themselves. In a direct conversation between two browsers, the other side's IP address can technically become known; this is part of the WebRTC procedure and cannot be switched off. About completed calls we store a call list: the two participants, the type of call (voice or video), start, time of answering, end, duration and whether the call came about at all.

Camera and microphone are only opened in the browser after your explicit permission. Replacing or blurring your camera background runs entirely on your device – we deliver the model used for it from our own servers; no image is sent anywhere for analysis. The streamer mode works the same way: when you share your screen it covers names, amounts and addresses on the display. It only changes what is shown on your screen and does not protect any data from third parties.

You can give guests without an account access to a room or to a Community via an invitation link. Before entering, the guest confirms an email address they provided themselves with a six-digit code; no account is created in the process. We store the address given, the name given and the times, in order to assign the access and to limit misuse of forwarded links. The legal bases are Art. 6(1)(b) and (f) GDPR.

Other participants can record content by their own means; we have no influence over that. Before you share sensitive information in a room, please check the participant list and the purpose of the room.

Stages and voice rooms can be recorded. A recording is never secret: while it runs, everyone in the room sees it from a clear notice – and indeed already before entering the room. Only the Community's moderation or the leadership of the respective stage may start, pause and end it.

Picture and sound of the room are recorded, including the presentations shown. The finished file ends up in the Community's media library, in its own folder next to the slides shown; it is therefore subject to the same access rights, folder retention periods and deletion options as other media of the Community. Third-party music that played in the room during a broadcast is expressly not included in the recording.

The legal basis is Art. 6(1)(b) GDPR for carrying out the event offered by the Community, plus our legitimate interest in talks being available for review afterwards under Art. 6(1)(f) GDPR. If you do not wish to be recorded, you can leave the room, take part without camera and microphone or object to the processing under Art. 21 GDPR; the people responsible for the Community decide about deleting a recording from their media library.

On stages, what is spoken can be transcribed as it happens, so that everyone can read along and statements remain verifiable. The transcript is created where the respective microphone is: the browser of the person speaking cuts their own contribution at the speech pauses and uploads only those sections. This means the name next to a line is measured rather than guessed from a mixed audio track – no voice comparison takes place.

The audio segments are transmitted to Azure OpenAI for conversion into text; for retention there, what is described in section 18 applies. On our side, each segment produces a line with the encrypted wording, the displayed name of the person speaking at the time of speaking, the start and the length of the segment. The transcript is a machine listening result and not a record of proceedings; the display points this out permanently.

The transcript can be seen and downloaded as a file by the people who are allowed to see the channel anyway. It is deleted automatically after 30 days. The transcript can be switched off per channel and is on by default; if it is switched off, no new lines are created while those already written remain. The legal basis is Art. 6(1)(b) GDPR as well as the legitimate interest of the Community and of founderi in accessibility and traceability under Art. 6(1)(f) GDPR.

If you use events or courses, we process registrations, acceptances and declines, waiting-list status, event and time-zone information, reminders, course assignment, progress, completed lessons, answers and, for paid events, the ticket status. Without a valid ticket we release neither the access link nor entry to the room; that is the function for whose sake the ticket status is processed.

Those responsible for a Community receive the overviews their Community needs – participant lists, acceptances and declines, course progress and aggregated usage figures. When uploading to the media library we additionally remember which channel a file came from, so that it can be filed automatically. The legal basis is Art. 6(1)(b) GDPR; for aggregated operational figures additionally Art. 6(1)(f) GDPR.

For an uploaded video, subtitles and a text version can be created. For this the audio track is transmitted in sections to the transcription service (section 18); the result sits as text and as a subtitle track next to the video and is translated into the reading person's language. Whether this happens is decided by a switch during upload — what was said then also appears as text, and for everyone allowed to see the video.

Communities have a public page that can be reached without signing in. Name, emblem, cover image, description, member count and – as far as the Community has set it up that way – faces and names of individual members may appear there. The related images are delivered via short-lived, signed addresses so that preview cards work in messengers without opening the entire media library. Anyone who has hidden their membership does not appear there (section 8).

Individual files from the media library and individual posts can be shared publicly on purpose – as a link, QR code or message. Whoever opens the link sees exactly this one item; the Community around it stays closed. For this we store the share itself, its deadline and access counts. A withdrawn share, deleted content, an expired deadline or a deleted account ends access immediately. People without an account can leave an invitation request on such a page; we then store the email address and message they gave for the Community's leadership and do not send any invitation email ourselves.

Communities can run a link page under their own address, where they gather an image, a description and references to the outside. It is public, is translated into all languages of the platform and counts clicks per reference as an estimate – the buttons point directly at their target and not at a redirector on our side. Existing personal link pages from before remain reachable.

For these pages we additionally keep an analysis that – like the visit count above – manages without any recognition: a tally kept on the server and condensed to the day, made up of view or click, the element concerned, the origin of the visit (referring website and campaign details from the address), device category, country and the language delivered. Nothing is stored or read on your device in the process – no cookie, no identifier, no counting pixel; § 25 TDDDG therefore does not apply. The legal basis is the Community's legitimate interest in a reach analysis of its own public page under Art. 6(1)(f) GDPR. No personal reference arises in this and none is established either.

Those responsible for a link page can additionally switch on the counting of returning visitors as such. Only then is an identifier stored in your browser, and only then do we ask you beforehand on the page expressly for your consent under § 25(1) TDDDG and Art. 6(1)(a) GDPR; without your agreement nothing is stored. The identifier does not leave your browser – all that is transmitted to us is whether this visit was the first or not. Your decision – including a no – is noted in your browser so that the question is not asked again; you can revoke it by deleting this page's website data in your browser.

Signed-in members can create short links. When opened, a short link first shows its destination before forwarding there, and we count the views. We store the destination address, the label, the creator, timestamps and view counts; the number of newly created short links is limited per account and day. Polls, too, can be shared publicly and embedded on other people's pages. A vote from outside requires a name and email address so that the same person doesn't vote several times; both are stored encrypted, and the key for the comparison is a non-reversible hash value that can compare but cannot return an address. Anyone voting first reads what happens with the address and explicitly ticks it off — without that tick no vote is created.

Anything you make public can be indexed by search engines, copied by third parties and spread further beyond our reach. The legal basis for these publications is Art. 6(1)(b) GDPR – they only happen because you or those responsible for a Community triggered them.

You can voluntarily attach a place to a post or a story. We store the place name – encrypted, with a searchable form alongside – and, if you allow it, coordinates. We deliberately round those to four decimal places: a story says “this café”, not “this table”. Without your input no location information arises; we do not derive a location from your IP address and do not store one from it either.

You can tag other members in a story. A tag is a statement about another person: the tagged person is notified and can remove themselves again, even against the wishes of the person who posted it. Music for a story comes from a licensed catalogue and is laid over it during playback, not baked into the video.

For the order in the feed we take spatial proximity into account alongside topics and attention. The location used for this comes solely from the profile field “Location” and from location details someone has attached to a post of their own; it is read at the moment of the query and not stored as a permanent attribute about you. Stories are visible for 72 hours; the details attached to them remain on the underlying post.

Posts, courses, stages and events may contain embedded third-party content – for instance videos from YouTube, Vimeo, Dailymotion, TikTok, Twitch, Loom, Streamable, Zoom, Spotify, SoundCloud, Imgur or Tenor. Only when such content is loaded or played can the respective provider process in particular your IP address, browser data and the time of the request. For YouTube we use, where possible, the variant without advertising cookies (youtube-nocookie.com). The providers' own privacy notices apply to their processing.

In the short-video reel, other people's short videos run alongside your own posts. We do not copy these videos: only what is known about a video is stored (address, title, channel, thumbnail); it is played in the embedded player of its own platform, with the consequences described above. The search for such videos is carried out by our server, not by your browser. Whether and how strongly your behaviour shapes the reel depends on your consent to personalisation (section 7); without it we only record what is necessary for operation.

With the stage radio, each browser plays the music itself via the music platform's player; we do not forward any audio. Here too a direct connection arises between your device and the provider.

Preview images and page snapshots for external links are fetched by our server, not by your browser – the linked page therefore learns nothing about you. When fetching, we automatically decline the external page's cookie banners, because we may not give consent on someone's behalf.

We load founderi's house typeface from Fontshare (Indian Type Foundry); individual technical files for displaying PDF documents come from the jsDelivr delivery network. Your browser connects to these providers for that and, for technical reasons, transmits your IP address. The legal basis is our legitimate interest in a consistent, functioning presentation under Art. 6(1)(f) GDPR.

GIF search has been removed. GIFs from GIPHY sent earlier can still be displayed; when they are fetched, Giphy, Inc. (USA) may receive your IP address and technical retrieval data. The legal basis is Art. 6(1)(f) GDPR, as this is necessary to display existing content.

The user interface is available in all languages of the platform; no processing of your content is needed for that. Members' content – messages, posts, channel and course texts, events, slides, subtitles – is by contrast machine-translated when needed. The text concerned is transmitted to Azure OpenAI (section 18) and the translation is cached in encrypted form so that the same sentence doesn't have to be translated repeatedly.

Whether a Community's content is translated is decided by the Community via the booked module; without that module it stays monolingual. Excluded are founderi's own content, publicly visible shop-window texts (such as a Community's card in Discover, link pages and short-link labels) as well as the example Community “Campus” – these are translated because they address people who are not members yet. Addresses and target addresses are never translated.

Various functions of founderi use AI models. The provider is exclusively Microsoft via Azure OpenAI; calls to OpenAI itself do not take place. The resource is located in an EU region, and the processing of individual requests is set to the EU data zone. Access happens via a managed identity without an API key and through a private network endpoint.

Depending on use, this affects: translations, subtitles and transcripts, voice messages and stage transcripts, text suggestions and the assistant, the creation and analysis of image and brand content, suggestions for landing pages, the topical classification of posts and notifications, content and word filters, the reading of uploaded receipts as well as the wording of certain emails. In each case only what the invoked function needs is transmitted – the text entered, the audio recording concerned, the selected image or the context data required for processing.

Under Microsoft's contractual terms, inputs and outputs are not used to train the foundation models, and OpenAI has no access to data submitted via Azure. Microsoft does, however, store inputs and outputs by default for up to 30 days for automated abuse monitoring, in the course of which authorised Microsoft staff can, in narrowly limited cases, view material. This retention lies outside our deletion processes; we point it out explicitly rather than keeping quiet about it.

For the optional setup assistant of a payout profile you can voluntarily upload photos of documents so that details such as name, address, date of birth or IBAN are read out as a form suggestion. No identity or authenticity check takes place in doing so. We do not store such images permanently; only the form data you have checked and confirmed is stored. Insofar as such an image contains a photograph of a face, the processing rests on your explicit consent under Art. 9(2)(a) GDPR; the fields can always be filled in by yourself without AI.

The legal basis is Art. 6(1)(b) GDPR for the product feature you requested, Art. 6(1)(f) GDPR for operationally driven analyses and Art. 9(2)(a) GDPR for special categories.

“Foundi” is the platform's assistant. When you talk to him, we process your input, the stored conversation history, reminders you have set and – only if your question requires it – individual details from your account. Which ones those can be is exhaustively listed in the code; Foundi receives nothing he has not asked for. He only makes changes to your account after an explicit confirmation and only within narrow limits. In public channels he answers without any information about an account.

Beyond that, Foundi remembers individual short notes about you so that you don't have to explain the same thing in every conversation — for example that you run two Communities. He writes these notes himself from what he picks up from you; they are overwritten per type rather than collected, and the wording of the conversation is not stored for this. Because that is a personality profile based on observed behaviour, it depends on your consent to personalisation: without it no note is created and none is read, and on withdrawal it is gone immediately (section 7).

Foundi can also be used by phone. Depending on the route, your microphone audio is first converted into text or processed directly by the speech model; the answer is read out. For the continuous call, your browser establishes a direct connection to Azure and thus transmits audio and IP address directly to Microsoft; we issue your browser a short-lived access token for this and do not see the conversation ourselves. On the alternative route, the connection is set up via our server. We count call duration and quotas; we do not keep the audio recording itself.

If you ask Foundi whether a claim is correct, or about a link, he searches the web. For this our server passes your question, or search terms derived from it, to the search engines DuckDuckGo, Brave Search and Mojeek and then fetches the pages found itself. Your browser makes no connection to these services, and we transmit no details about you – but we do transmit the text of your question. Please therefore do not include any confidential information in such a question.

For prices, rates and headlines, the server additionally fetches publicly available sources (Stooq, Yahoo Finance as well as Google News as an RSS news overview). These requests, too, come from us, not from your device. This expressly does not constitute investment advice.

On publicly shared pages Foundi can be addressed without signing in. There he knows only the public entry questions and the content of the shared page; details about accounts are not available to him there. To protect against misuse we limit the number of such requests. Whether Foundi can be addressed in a Community at all is decided by its moderation.

Before full use of the platform we verify members' identity. Since August 2026 this check is carried out by the service Didit (verification.didit.me). Stripe Identity was used before that; for accounts that began their check there, and as a fallback route, that path remains in place. The purpose of the check is that behind every name on founderi there is a verified human, as well as preventing multiple and circumvention accounts; the legal basis is Art. 6(1)(b) and (f) GDPR, and for keeping the record also (c).

To create a verification session we transmit to Didit a pseudonymous identifier for your account, your email address, your language and – where available – the name and date of birth we hold, as an expected value. The verification itself takes place on Didit's pages: there you enter your identity document and the further evidence required by the verification flow directly with Didit. Didit's privacy notice applies to that processing; if the flow includes a face match, biometric data is processed for which your explicit consent is obtained during the verification (Art. 9(2)(a) GDPR).

What comes back to founderi is the check result, the session identifier, timestamps, in case of failure an error identifier, and from the checked document first and last name and date of birth. We take these details into your account; they take precedence over self-typed entries, because the name under your posts is worth only as much as the verification behind it. The address that Didit also supplies we explicitly do not take over. We do not receive identity images by this route.

The result reaches us via a signed callback from Didit; in addition we query the status ourselves. We store the result in the form in which the platform reads it, and alongside it the provider's unchanged information as evidence. A change of provider does not delete any earlier proof of verification.

For people for whom the check via the service provider does not work – for instance because a document is not supported – we offer a check of our own. It is voluntary and a second route, not a replacement. In it you photograph your identity document and your face, and an image model compares the two. That is the processing of biometric data for unique identification within the meaning of Art. 9(1) GDPR; it takes place solely on the basis of your explicit consent under Art. 9(2)(a) GDPR.

We obtain consent before the first image is created: without it the procedure is not even opened, and without an opened procedure no image can be uploaded. Before the actual comparison we check a second time whether it still applies. As evidence we store the time and the version of the consent text on the account and on the respective procedure, plus an immutable log line; expressly no image is kept as proof of consent. You can withdraw consent at any time – the ongoing procedure including all images is then cleared immediately.

At most five images are captured, each with its own purpose: the front of the document as the object of comparison, the back because of the machine-readable zone (not needed for a passport), a face image from the front and two head turns as proof of authenticity. The server does not accept a sixth capture. There is no file picker; an image from the gallery proves nothing about the person in front of the camera. Sharpness and brightness measurement during capture run exclusively in your browser.

The images are transmitted exclusively in encrypted form and are stored in a dedicated storage area that is delivered neither via the general media route nor via any other address. They are not included in backups. For the comparison we transmit them to Azure OpenAI (section 18) – expressly without the details you typed in yourself; the comparison with our records then takes place in our own code. No face vector, biometric template or comparable feature is created at any point, not even temporarily.

With the decision the purpose ends, and with it the storage: images, machine-readable zone, document number, document type, issuing country, expiry date as well as the name and date of birth read from the document are deleted in the same move. What remains is a review note – the calculation, the result, the time, who decided and under which version of the consent. The question “why was this account approved?” must still be answerable a year later; the question “what did the ID look like?” must not. An abandoned process is cleared after two hours, a submitted one that nobody decided on after seven days; a process submitted for human review keeps its images until the decision, because otherwise nobody could decide.

The images of an ongoing check are seen exclusively by members of the platform leadership with the role “admin” – not support, not other team roles. Every image request that is opened is logged, and the images are delivered with a no-caching directive. After deletion this access no longer responds.

One point should be named openly: our nightly database backup contains no images, but it does contain the record row. If it runs while a check is currently open, the document details read from it may be contained in a backup until the retention period expires. We accept this knowingly, because backups with excluded columns would destroy the restorability on which far more depends.

For paid services, subscriptions, one-off storage or content purchases, tickets, invoices, refunds and payouts we use Stripe. Depending on the transaction, Stripe Payments Europe, Ltd. (Ireland) and/or further companies of the Stripe group, in particular Stripe, Inc. (USA), are involved.

Processed and transmitted are in particular name, email address, billing and address data, purchase item, amount, currency, tax information, payment and transaction status as well as Stripe customer, session and account identifiers. Card and account details you enter directly in the input forms provided by Stripe; we do not store complete payment data. If you break off a purchase, we keep what you wanted to buy and where you can return to, so that we can remind you of it once; before every such reminder we check whether the item has meanwhile been bought.

If you take part in the partner programme, we also process your referral chain (who recruited you and whom you recruited), the resulting commissions, your payout profile including bank details or debit card, tax details and the credit notes issued. For the payout, Stripe Connect collects further details directly from you. Credit notes contain the legally required details and are kept in line with commercial and tax retention periods.

People in your team see your name and your position in it; they do not see the amounts others pay for their subscription. If your position in a team is changed, you are notified about it. The legal bases are Art. 6(1)(b) GDPR, Art. 6(1)(c) GDPR for commercial and tax obligations and Art. 6(1)(f) GDPR for fraud prevention. Stripe's privacy notices apply in addition.

Whoever comes to founderi via a referral link is assigned to the referring person; whoever came without one can add a referral themselves within a deadline. Both are a statement about two people at once and are therefore logged. One exception we name explicitly: in rare individual cases and by arrangement, the platform leadership can hook founderi itself into a referral chain. This action triggers no notification; it requires a justification and appears with name and time in the audit log. You can request information about your own position at any time.

We process voucher codes together with the redeemed code, the scope of services unlocked and the time of redemption, so that a code is not used more than once.

If an event is cancelled or a Community is closed, we refund of our own accord what was paid and not delivered — for a Community the unused remainder of the current billing period pro rata, for tickets and courses not worked through the full amount. For this we process your purchase and payment data and write to you; whoever has paid receives a different message from whoever has not, because the question about the money comes before all others.

For members of the founder club we additionally process the share in the monthly result: the share per seat, the monthly settlement and the payouts resulting from it. Inside the club, a month's distribution can be viewed with all amounts — your own row with a name, the others only as “Member 2” to “Member 21”, because a fixed share remains a matter between the company and the individual person. The platform leadership may look into this area without being counted; every such look is logged, and the list of these accesses is open to the club members.

We send emails via the SMTP infrastructure configured for founderi: login codes, invitations, security and account notices, purchase and payout receipts, event and system notifications, notices about direct messages left unread and — unless you have objected — digests and bulk mails. The legal basis is Art. 6(1)(b) GDPR, and for operationally necessary notices and for direct marketing to existing members additionally Art. 6(1)(f) GDPR.

For every email sent we log: type of mail, recipient address and its provider, language, subject, delivery status, the identifier of the outgoing mail and its response, in case of failure the error text and error class, number of attempts, duration and size. That answers the question “did the mail go out?” with evidence rather than with our word. If an address bounces permanently, we put it on a block list so that we do not write to it again.

We explicitly do not use a tracking pixel and do not measure whether an email was opened. Only clicks are measured: links in our emails go through a short redirect at which we store the time of the first click and the device class (phone, tablet, computer) – never the full browser identifier. The destination is stored on the row and not in the link, so that this does not become an open redirect. From how you click on our own mail we derive at what time of day we write to you and how often – whoever does not react hears from us less often.

Some reminder emails are written by an AI model tailored to your situation (section 18). For this it receives: what the email refers to, your location and local time, your field and how long you have been with us. It expressly does not receive: your address and your date of birth. The wording of every email sent this way is stored by us so that it remains traceable what was actually written to you.

Members who recruited others can write them a message at most every three days, delivered via our sender address with their name above it. External links do not go out in the process, replies happen inside the platform; the person writing does not learn your address.

You can unsubscribe from bulk mails and reminder tracks at any time – via the unsubscribe link, your mail program's one-click unsubscribe or in your settings. Transactional mail (login code, receipt, security notice) cannot be unsubscribed from, because it is part of performing the contract. When you unsubscribe we ask for the reason voluntarily; the unsubscription takes effect regardless of your answer.

Push notifications are optional. If you switch them on, we store a push subscription with a technical endpoint address and cryptographic keys. Delivery happens via the push service of your browser or operating system, for example from Apple, Google or Mozilla. The legal basis is your consent under Art. 6(1)(a) GDPR; you can withdraw it in your browser or device settings and within the platform.

To protect members and the platform, we process reports about content or people, the stated reason for the report, optional explanations, the content concerned, times, account identifiers involved, moderation decisions and, where applicable, measures such as warnings, restrictions, blocks or deletions. The same applies to technical signals of abuse such as suspicious login attempts, exceeded request limits or repeatedly faulty requests, as well as to browser reports about blocked content.

An automated spam detection evaluates several signals and puts conspicuous cases before the team. It does not block anyone on its own; a person decides about burdensome measures. If the moderation removes or corrects someone else's post, the change is recognisable as such to everyone, the earlier version is kept and the intervention is logged.

In the event of attacks and repeated misuse we can block individual IP addresses temporarily; the address, the reason and the time are stored. If an account is blocked, we store characteristics to enforce the block in the form of a non-reversible fingerprint (verified name with date of birth, identity-check identifier, bank details, email address) as well as a deliberately shortened recognition label. The plain-text values are not stored for this; this list can answer exactly one question, namely whether it is the same person. The legal basis is Art. 6(1)(f) GDPR.

In the case of a report, the reported person may learn that a measure has been taken. We do not pass on the identity of reporting persons without a legal basis; however, we cannot promise complete confidentiality without limitation in legal proceedings or where disclosure is mandatory. We open a reporting person's inbox only with their explicit release.

For support requests we process your description, attachments, the course of the case, the link to your account and the team's replies. The assistant takes on the first categorisation; it hands a case over to people when it can't help further. As long as a case is open, the assistant knows about it, so that it does not mistake a question about the status for a new request.

For troubleshooting, the platform leadership can view the interface for a limited time through a member's eyes. This access is tied to several conditions, is logged and changes nothing for the person concerned: they do not appear as online, receive no Aktivitätspunkte and their sessions remain untouched. Administrative actions by the team — in particular changes to accounts, blocks, releases and opening an identity image — are recorded in an audit log.

The team can keep internal notes on an account — for example the status of a case or an agreement that was reached. They carry the name of the person writing and the time, are not visible to the member and are subject to your right of access like everything else. To handle a case, the back office compiles the details belonging to an account in one overview; it shows nothing that is not stored anyway. The legal basis is Art. 6(1)(f) GDPR.

Team accounts can, on request, appear under a platform name instead of the legal name. This display changes nothing about receipts, invoices, identity checks and logs: there the person remains named. Analyses of operations (costs, load, funnel, delivery rates) we keep aggregated as far as possible; the legal basis is Art. 6(1)(f) GDPR.

founderi asks for your view in four places: when you arrive, about your goal and then about what is in your way and how you know us; at most once a week with a short question in the feed; when you unsubscribe from mail, about the reason; and when you delete your account, about the reason. All of these details are voluntary, there are no Aktivitätspunkte for them, and clicking a question away is itself a valid answer – that same question won't come back.

What is stored is the answer you chose and, if you write one, your free text. The answers flow into aggregated evaluations that show where the platform gets stuck; the answers from the welcome flow additionally determine the order of the suggestions you see afterwards. The legal basis is our legitimate interest in evidence-based rather than guessed product development under Art. 6(1)(f) GDPR; we delete your details along with your account.

The data comes in principle from you – from your entries, uploads and actions within the platform. In addition we receive data from other members when they invite you, mention you, tag you, write to you, register you for an event or share content with you. From service providers we receive status and reference data: from Stripe on payments and payouts, from Didit on the result of the identity check along with the name and date of birth from the document. Technical data arises automatically during use. For people who signed up to the waiting list on founderi.io before the platform launched, the address, name, referral code and assignment to the referring person come from that waiting list; they were taken over into the platform at launch.

The details required for registration, authentication, identity verification, payment processing or a chosen function must be provided; without them we cannot provide the account, the payment, the check or the respective function, or not fully. Voluntary profile details, location details, optional AI aids, push notifications and consent-based analysis are not a prerequisite for core use.

We do not make automated decisions in individual cases, including profiling under Art. 22 GDPR, that produce legal effects concerning you or similarly significantly affect you. Automated checks – request limits, malware scanning, content filters, spam detection, the preliminary assessment of an ID check – serve to protect the platform and to prepare the decision; burdensome decisions are made by a person. A rejection of an identity by our own check without human involvement is ruled out.

We use service providers only insofar as this is necessary for operation, security and the functions you request. Insofar as service providers process personal data on our behalf, we conclude the required data-processing agreements under Art. 28 GDPR; otherwise we base the processing on whichever data-protection role and legal basis fits.

The main recipients are: Microsoft (Azure Container Apps, PostgreSQL, Blob Storage, Key Vault, Azure Monitor and Azure OpenAI for all AI features), Hetzner Online GmbH (servers of the voice and video rooms), Stripe (payments, Connect, payouts and previous identity checks), Didit (ID check), the configured SMTP service for sending email, the push services of the browser and operating-system providers, Fontshare and jsDelivr for font and display files, the search engines DuckDuckGo, Brave Search and Mojeek as well as the price and news sources Stooq, Yahoo Finance and Google News for queries from our server, and the operators of content embedded by members.

Inside founderi, only people who need it for their tasks are given access. Role and permission concepts limit access to Community content, administrative functions and particularly protected areas; for ID images the narrowest level applies (section 21). We also pass on personal data where this is necessary to fulfil legal obligations or where there is an enforceable official or judicial order.

Some service providers we use, or their subprocessors, may be located outside the European Economic Area or access data from there – in particular Stripe, GIPHY as well as individual push, search, price-data and embedding services. With Microsoft, too, third-country links may arise depending on the service contract, support case or configuration; for the Azure production resources, processing is intended to take place in the European regions named above and, for the AI calls, in the EU data zone.

Insofar as a transfer to a third country takes place, we ensure the requirements of Art. 44 et seq. GDPR – in particular via an adequacy decision, a certification under the EU-US Data Privacy Framework where applicable, or the European Commission's standard contractual clauses together with additional safeguards where necessary. You can request information about the guarantees relevant in the individual case via the contact details given in the legal notice.

We store personal data only for as long as is necessary for the respective purpose. Account data and settings we store for the lifetime of the account. Community content, messages and media stay stored until the entitled person deletes them, a set deadline expires or the account or the Community is removed.

Fixed retention periods apply in particular to: server and application logs (30 days), stage transcripts (30 days), usage events with consent (90 or 180 days respectively), images and document details of an ID check (with the decision, at the latest after two hours if abandoned or seven days without a decision) and, for media library folders, the period set by the Community. Payment, invoice, credit note and tax-relevant documents we keep for the legally required period; as a rule that is six or ten years.

For restorability we back up the database: Azure keeps a point-in-time backup of 14 days, and in addition we create a daily logical dump into a separate storage area (30 daily states, twelve weekly states, twelve monthly states – a single dump thus lives for at most about 16 months). Deleted data may still be present in a backup until the respective backup state expires and is processed during that time solely for restoration and for security purposes. Files in object storage – and thus also ID images – are not backed up; a file deleted there is gone immediately and for good.

We take appropriate technical and organisational measures under Art. 32 GDPR. These include in particular transport encryption via TLS, encrypted storage of message content and transcripts, access controls and role-based permissions, an optional second sign-in factor enforced on all protected routes and not just on the pages in front of them, separate storage areas for media, receipts, club documents, identity images and backups, private network connections for central Azure services, protection against access to internal addresses when fetching external pages, request limits against abuse, scanning of uploads for malware, regular backups as well as monitoring and alerting of operations.

Access credentials for the application, database and services are kept in Azure Key Vault; the application reaches them via a managed identity, so no credentials appear in the source code or in the application in plain text. For the AI resource and the object storage there are no API keys at all. We adapt security measures continuously to technical developments and to the risk.

Absolute security cannot be guaranteed for internet-based services. If we detect a personal data breach, we fulfil our reporting and notification duties under Art. 33 and 34 GDPR.

Subject to the respective legal conditions, you have the right of access (Art. 15 GDPR), rectification (Art. 16 GDPR), erasure (Art. 17 GDPR), restriction of processing (Art. 18 GDPR), data portability (Art. 20 GDPR) and to object to processing based on Art. 6(1)(e) or (f) GDPR (Art. 21 GDPR). Consents you have given – for usage analysis, for push notifications and for the face match during identity verification – can be withdrawn at any time with effect for the future, without affecting the lawfulness of the processing carried out up to that point.

You can delete your account yourself in the account settings under “Account & Security”. Before deleting, the platform shows — calculated from your own data — what will happen, including the unpleasant parts: your memberships end, Communities you founded disappear with you, Aktivitätspunkte along with level and streak lapse. Your posts and messages stay, from then on without your name as “Deleted member” — they are part of conversations other people are involved in. The referral chain of the people who came via you remains, so that their commission keeps running. Invoices, credit notes and payout receipts are kept as long as the tax periods run. Your email address becomes free again.

If a payout is still pending, deletion is blocked for that time — otherwise an account still owed money would disappear. We ask for a reason for your departure, but it is voluntary and does not hold up the deletion. A self-service export of your data is not currently available; for access and data portability please use the contact details given in section 1. We reply within the statutory deadlines.

You also have the right to complain to a data protection supervisory authority, in particular in the member state of your habitual residence, your place of work or the place of the alleged violation (Article 77 GDPR).

We update this privacy statement when the legal situation, processing operations, services used or security measures change. What counts is the version published on this page at the time. If the scope of processing based on your consent changes, we obtain that consent anew instead of letting the old one quietly stay in force.