What one InterMIND meeting is built from

Almost every product is built from the same default stack — the big proprietary SaaS defaults everyone reaches for. They're the frictionless path. At every layer where your meeting data actually lives, we took a different one: our own code, or open-source we could self-host.

This is the companion to Where one InterMIND meeting actually runs, which mapped the geography — where each service executes and what data passes through it. This post answers what a security team asks next: what is this thing built from — and can we read it, audit it, and replace it?

Not where it runs — what it's made of, layer by layer.

The defaults, and what they cost

Every product is a stack of choices. For most products, most of those choices are made by default: Google Analytics, Firebase, the Google Translate API, Auth0, React. They're the frictionless path, and for most teams that's a reasonable call. The trade-off is that each one puts a part of your stack behind a vendor you can't read, can't audit, and can't leave without a rewrite.

We made a different choice at every layer where your meeting data actually lives: our own code, or open-source software we could self-host. Where a layer doesn't touch the content of your meeting, we stay pragmatic and say so. Here's the whole picture.

The spine: the engine is our code, not a third party's

Start with the layer that matters most, because most of your meeting flows through it. Real-time transport and voice/chat translation both run on mind-sdk + the Mind API — our own engine, on OVH France. The default way to build a translated meeting is to bolt a real-time SaaS (LiveKit) onto a translation API (DeepL, Google); we run neither in the live path. No third-party translation model is in the loop. (We do use DeepL — but only for documents dropped into chat, not the live voice/chat path; see the runtime map. We covered the pipeline mechanics in Inside the four translation pipelines.)

Here's the part that isn't in the runtime map: the SDK your meeting runs on is open source under the BSD 3-Clause license — the mind-sdk client is public at gitlab.com/mindlabs/api/sdk, copyright MindMeeting OÜ, our Estonian IP entity. It speaks to the Mind API at api.mind.com, which we run ourselves on OVH France.

This isn't a "look, but don't touch" source-available arrangement. BSD 3-Clause is a permissive, OSI-approved license. Your security team can clone the SDK, read exactly how your audio and text are captured, framed, and streamed, and audit that integration against your own requirements. The server-side engine it talks to is ours — not a third party's black box — and a fully self-hostable engine for a tenant who needs it is on our roadmap, not something we offer today. We'll update this post the moment it ships.

Layer by layer: the default vs. what we run

Two threads run through that table. Open-source where the tool processes your data — so it can be audited, and in principle self-hosted. Open standards (Postgres, the S3 API, OIDC) where we depend on infrastructure — so nothing is locked to one vendor's pricing or compliance posture. Postgres can move to any Postgres host; storage can move to any S3 store; auth federates to the identity provider you already run. The last row sits on a third axis: the CRM holding customer records is EU-domiciled (Pipedrive, Estonian) rather than a US sales platform — not open-source, but not under US jurisdiction either.

A couple of these deserve a sentence more. PostHog is open-source and self-hostable; we run it on PostHog's EU cloud and proxy it first-party through our own origin, so the events aren't silently dropped by ad-blockers and don't transit a third-party analytics domain. Authentication never goes to a third-party auth SaaS that would sit between you and your sessions — we run the OIDC flow ourselves and federate to your existing Google or Microsoft identity. And the fonts on every page are served from our own domain; the only place Google Fonts appears in our codebase is an offline brand-asset script, never the app your users load.

Where we're pragmatic — said out loud

We don't pretend the whole stack is hand-rolled or non-US. It isn't, and a post that claimed otherwise would be contradicted by our own runtime map.

The plumbing — hosting and SSR (Vercel), the meeting server's compute (Fly.io), payments (Stripe), transactional email (Resend) — runs on US-domiciled SaaS. Stripe and Resend handle billing and invites and never see meeting content. Vercel and Fly are rented compute: our own code runs on them, and the meeting server on Fly does handle the live session and the transcript our digest reads — but that's our code on their machines, not a vendor product ingesting your meeting. All of it executes in the EU at runtime (the subject of the runtime map).

That's a deliberate, bounded trade-off: own and open-source the data plane; use the best available SaaS for the control plane. Naming it is the point — "sovereignty" means little if the exceptions aren't on the table next to the wins.

The post-meeting AI steps, and the plan

No proprietary US-domiciled model touches meeting-derived content. The language-model steps that run after the call — the AI digest (topics, decisions, action items), the post-meeting summary, and the AI note-editor — all sit on EU processors. The digest and the editor's generative actions run on EU-hosted Mistral with zero-data-retention (reached through Vercel's AI Gateway, pinned to the Mistral provider). The summary and the editor's translate action run on our own EU engine on OVH — the same one behind live voice and chat. Real-time voice, chat, notes, and documents never went near a general-purpose LLM in the first place.

The only US model still in the loop judges our public translation benchmark — scoring machine translations of fixed FLORES-200 reference sentences, never anyone's meeting.

We're still going further on the EU-Mistral steps: an owner-controlled opt-out to turn the digest off entirely, and a self-hosted, open-weights summarization model on OVH (Kimi-class) to replace the external Mistral. The point of the open-weights route isn't whose lab trained the weights — it's that open weights can run on infrastructure we control, which keeps it on the same open-and-self-hostable axis as the rest of the data plane. Both are on the roadmap, not shipped; we'll update this post when they land.

Why this matters beyond us

This isn't engineering for its own sake. The reason to build a stack this way shows up on your side of the contract:

1. Auditable. The SDK your meeting runs on is open-source code your security team can read, and the engine behind it is our own — not a third party's black box.
2. Portable. Open standards at every data layer — Postgres, S3, OIDC — mean no proprietary lock-in. What can be moved isn't tied to a single vendor.
3. Self-hostable. The open-standard data layers — Postgres, S3, OIDC — already run on infrastructure you control; a fully self-hosted translation engine is on the roadmap for the tenant who needs it.

This is the picture on 2026-06-07. We'll update it when the stack changes — a vendor swap, a layer rebuilt, the digest model replaced. The current configuration is verifiable in our open vercel.json, our nuxt.config.ts, and the BSD-3-Clause mind-sdk repository linked above.

If a layer here looks wrong, or your security review needs an answer this map doesn't give, write us. We'd rather correct a missing detail than have you find it in a code audit.

Sources: the mind-sdk repository (BSD-3-Clause), FLORES-200; stack facts verified against the deployed configuration (vercel.json, nuxt.config.ts) and the shipped code, checked August 2026.