Waaruit één InterMIND-meeting is opgebouwd
Bijna elk product is opgebouwd uit dezelfde standaard stack — de grote propriëtaire SaaS-standaarden die iedereen gebruikt. Het is het pad van de minste weerstand. Op elke laag waar je meeting-data daadwerkelijk leeft, hebben we een andere keuze gemaakt: onze eigen code, of open-source die we zelf konden hosten.
Dit is de aanvulling op Waar één InterMIND-meeting daadwerkelijk draait, waarin de geografie in kaart werd gebracht — waar elke service wordt uitgevoerd en welke data erdoorheen stroomt. Dit bericht beantwoordt wat een securityteam daarna vraagt: waaruit is dit opgebouwd — en kunnen we het lezen, auditen en vervangen?
Niet waar het draait — waaruit het bestaat, laag voor laag.
De standaarden, en wat ze kosten
Elk product is een stack van keuzes. Voor de meeste producten worden de meeste van die keuzes standaard gemaakt: Google Analytics, Firebase, de Google Translate API, Auth0, React. Het is het pad van de minste weerstand, en voor de meeste teams is dat een redelijke keuze. De afweging is dat elk van deze een deel van je stack achter een vendor plaatst die je niet kunt lezen, niet kunt auditen en niet kunt verlaten zonder een herschrijving.
Op elke laag waar je meeting-data daadwerkelijk leeft, hebben we een andere keuze gemaakt: onze eigen code, of open-source software die we zelf konden hosten. Waar een laag de inhoud van je meeting niet raakt, blijven we pragmatisch en zeggen we dat ook. Hier is het hele plaatje.
De ruggengraat: de engine is onze code, niet die van een derde partij
Begin met de laag die het meest telt, omdat het grootste deel van je meeting erdoorheen stroomt. Real-time transport en stem/chat-vertaling draaien beide op mind-sdk + de Mind API — onze eigen engine, op OVH France. De standaardmanier om een vertaalde meeting te bouwen is om een real-time SaaS (LiveKit) aan een vertaal-API (DeepL, Google) vast te koppelen; we draaien geen van beide in het live pad. Er zit geen vertaalmodel van een derde partij in de loop. (We gebruiken wel DeepL — maar alleen voor documenten die in de chat worden gedeeld, niet voor het live stem/chat-pad; zie de runtime-kaart. We hebben de pijplijnmechanismen behandeld in Binnen de vier vertaalpijplijnen.)
Hier is het deel dat niet in de runtime-kaart staat: de SDK waarop je meeting draait is open source onder de BSD 3-Clause-licentie — de mind-sdk-client is openbaar op gitlab.com/mindlabs/api/sdk, copyright MindMeeting OÜ, onze Estlandse IP-entiteit. Deze communiceert met de Mind API op api.mind.com, die we zelf draaien op OVH France.
Dit is geen "kijken, maar niet aanraken" source-available regeling. BSD 3-Clause is een permissieve, OSI-goedgekeurde licentie. Je securityteam kan de SDK klonen, exact lezen hoe je audio en tekst worden vastgelegd, ingekaderd en gestreamd, en die integratie auditen tegen je eigen vereisten. De server-side engine waarmee het communiceert is van ons — geen black box van een derde partij — en een volledig zelf-hostbare engine voor een tenant die dit nodig heeft, staat op onze roadmap, maar bieden we vandaag nog niet. We updaten dit bericht zodra het wordt uitgeleverd.
Laag voor laag: de standaard versus wat wij draaien
| Laag | De gebruikelijke standaard | Wat wij draaien | Waarom het voor jou belangrijk is |
|---|---|---|---|
| Real-time + vertaalengine (stem + chat) | LiveKit + een vertaal-API (DeepL / Google) | mind-sdk (BSD-3-Clause-client) + onze Mind API, OVH France | De zwaarste datastroom is onze eigen engine, niet een model van een derde partij — en de client-SDK ervan is open en auditabel |
| Frontend-framework | React (Meta) / Next.js | Vue + Nuxt | Door de gemeenschap bestuurde OSS — geen enkel bedrijf is eigenaar van het framework waarop je UI draait |
| Product analytics | Google Analytics | PostHog | Open-source, EU-cloud, proxied als first-party via ons eigen domein — gebruiksdata stroomt niet naar een advertentieplatform van een derde partij |
| Lettertypen | Google Fonts CDN | Zelf gehost (@nuxt/fonts) | Geen callout naar lettertypen van een derde partij vanaf de pagina die je gebruikers laden — een terugkerende GDPR-bevinding, vermeden |
| Authenticatie | Auth0 / Clerk / Firebase Auth | Zelf gedraaide OIDC, gefedereerd naar je Google / Microsoft | Geen auth-tussenpersoon houdt je sessies vast — je brengt je eigen identity provider mee |
| Documentvertaling | Google Translate | DeepL (Cologne) | Gespecialiseerde EU-vendor, Duitse verwerking |
| Content / docs | Contentful / Sanity (headless CMS) | Nuxt Content (git-tracked markdown) | De woorden op onze site staan in onze repo, niet in de database van een vendor |
| Applicatiedatabase | Firestore / DynamoDB (proprietary) | Postgres (op Neon) | Open standaard — draagbaar naar elke Postgres-host, geen propriëtaire query-API om te herschrijven |
| Objectopslag | Proprietary blob API's | Tigris (S3-compatibel) | Open protocol — opnames en exports zijn draagbaar naar elke S3-opslag |
| CRM / sales | Salesforce / HubSpot | Pipedrive (Ests) | Klant- en dealrecords staan in een in de EU gevestigd CRM, niet op een Amerikaans salesplatform |
Er lopen twee draden door die tabel. Open-source waar de tool je data verwerkt — zodat het auditabel en in principe zelf te hosten is. Open standaarden (Postgres, de S3-API, OIDC) waar we afhankelijk zijn van infrastructuur — zodat niets is vastgezet aan de prijsstelling of compliance-houding van één vendor. Postgres kan naar elke Postgres-host verhuizen; opslag kan naar elke S3-opslag verhuizen; auth federeert naar de identity provider die je al draait. De laatste rij staat op een derde as: het CRM dat klantrecords vasthoudt, is EU-gevestigd (Pipedrive, Ests) in plaats van een Amerikaans salesplatform — niet open-source, maar ook niet onder Amerikaanse jurisdictie.
Een paar hiervan verdienen nog een zin. PostHog is open-source en zelf te hosten; we draaien het op de EU-cloud van PostHog en proxied het first-party via onze eigen origin, zodat de events niet stilletjes door ad-blockers worden geblokkeerd én niet via een analyticsdomein van een derde partij gaan. Authenticatie gaat nooit naar een auth-SaaS van een derde partij die tussen jou en je sessies zou zitten — we draaien de OIDC-flow zelf en federeren naar je bestaande Google- of Microsoft-identiteit. En de lettertypen op elke pagina worden geserveerd vanaf ons eigen domein; de enige plek waar Google Fonts in onze codebase voorkomt, is een offline brand-asset-script, nooit de app die je gebruikers laden.
Waar we pragmatisch zijn — luid en duidelijk
We doen niet alsof de hele stack handmatig is gebouwd of niet-Amerikaans is. Dat is niet zo, en een bericht dat het tegendeel beweerde, zou worden tegengesproken door onze eigen runtime-kaart.
De basis — hosting en SSR (Vercel), de compute van de meetingserver (Fly.io), betalingen (Stripe), transactionele e-mail (Resend) — draait op in de VS gevestigde SaaS. Stripe en Resend handelen facturering en uitnodigingen af en zien nooit de inhoud van je meeting. Vercel en Fly zijn gehuurde compute: onze eigen code draait erop, en de meetingserver op Fly handelt inderdaad de live sessie en het transcript af dat onze digest leest — maar dat is onze code op hun machines, niet een vendorproduct dat je meeting ophaalt. Al dit alles wordt tijdens runtime in de EU uitgevoerd (het onderwerp van de runtime-kaart).
Dat is een weloverwogen, afgebakende afweging: de data plane in eigendom hebben en open-source maken; de best beschikbare SaaS gebruiken voor de control plane. Het benoemen hiervan is precies het punt — "soevereiniteit" betekent weinig als de uitzonderingen niet naast de overwinningen op tafel liggen.
De AI-stappen na de meeting, en het plan
Geen propriëtair in de VS gevestigd model raakt content die is afgeleid van je meeting. De taalmodelstappen die na het gesprek worden uitgevoerd — de AI digest (onderwerpen, beslissingen, actie-items), de post-meeting summary en de AI note-editor — draaien allemaal op EU-processors. De digest en de generatieve acties van de editor draaien op EU-gehoste Mistral met zero-data-retention (bereikt via Vercel's AI Gateway, vastgepind op de Mistral-provider). De samenvatting en de actie vertalen van de editor draaien op onze eigen EU-engine op OVH — dezelfde engine achter live stem en chat. Real-time stem, chat, notities en documenten zijn in de eerste plaats nooit in de buurt geweest van een algemene LLM.
Het enige Amerikaanse model dat nog in de loop zit, beoordeelt onze publieke vertaalbenchmark — het scoren van machinevertalingen van vaste FLORES-200-referentiezinnen, nooit iemands meeting.
We gaan op de EU-Mistral-stappen nog verder: een door de eigenaar gecontroleerde opt-out om de digest volledig uit te schakelen, en een zelf-gehost, open-weights samenvattingsmodel op OVH (Kimi-klasse) om de externe Mistral te vervangen. Het punt van de open-weights route is niet wiens lab de weights heeft getraind — het is dat open weights kunnen draaien op infrastructuur die we beheersen, wat het op dezelfde open-en-zelf-hostbare as houdt als de rest van de data plane. Beide staan op de roadmap, zijn nog niet uitgeleverd; we updaten dit bericht wanneer ze landen.
Waarom dit verdergaat dan ons
Dit is geen engineering om het engineering. De reden om een stack op deze manier te bouwen, zie je aan jouw kant van het contract:
- Auditabel. De SDK waarop je meeting draait is open-source code die je securityteam kan lezen, en de engine erachter is van ons — geen black box van een derde partij.
- Draagbaar. Open standaarden op elke datalaag — Postgres, S3, OIDC — betekenen geen propriëtaire lock-in. Wat verplaatst kan worden, is niet gebonden aan één vendor.
- Zelf te hosten. De open-standaard datalagen — Postgres, S3, OIDC — draaien al op infrastructuur die jij beheerst; een volledig zelf-hostbare vertaalengine staat op de roadmap voor de tenant die dit nodig heeft.
Dit is het plaatje op 2026-06-07. We werken het bij wanneer de stack verandert — een vendor vervangen, een laag herbouwd, het digest-model vervangen. De huidige configuratie is verifieerbaar in onze open vercel.json, onze nuxt.config.ts, en de hierboven gelinkte BSD-3-Clause mind-sdk-repository.
Als een laag hier verkeerd lijkt, of je security-beoordeling een antwoord nodig heeft dat deze kaart niet geeft, schrijf ons. Liever corrigeren we een ontbrekend detail dan dat je het vindt in een code-audit.
Bronnen: de mind-sdk-repository (BSD-3-Clause), FLORES-200; stack-feiten geverifieerd tegen de uitgerolde configuratie (vercel.json, nuxt.config.ts) en de uitgeleverde code, gecontroleerd in augustus 2026.