All ten
Mammito logo

Mammito

Multi-tenant care platform

Product, architecture, API, three frontends, infrastructure

Live
mammito.de

Families searching for a midwife find one in a verified catalogue by postcode and service, book and pay for the appointment, and meet in an encrypted browser consultation with nothing to install. Providers run their caseload from a cockpit: calendar, care pathway, documents, messaging and payouts. Every practice is its own tenant, isolated at the database layer rather than by convention.

Client portalProvider cockpitAdminPublic catalogueLanding
29API modules
9interface languages
2video providers, one adapter
RLSisolation in Postgres

Screens

Key engineering

database-enforced tenant isolationmulti-tenant routingprovider-agnostic videoStripe Connect payoutsdelegated access with audit trailGDPR consent handlingcatalogue searchscheduling and availability

Under the hood

Architecture

One modular API serving several host-routed frontends, with the tenant boundary pushed down into the database rather than enforced by convention in application code. Replaceable parts — video, payments — sit behind adapters.

Data & state

Relational, with isolation applied per practice at the storage layer, so a query that forgets its tenant returns nothing instead of another practice's client records. Media in object storage, domain events for cross-module reactions.

Runs on

A long-running API with a relational store and a cache. The public catalogue is generated ahead of time and served separately from the authenticated application.

Operational risk

Health data raises the floor: consent handling, encrypted consultations and audit trails were requirements from the first line, not a compliance pass before launch. Isolation is the one guarantee that must never fail, so it is enforced where an application bug cannot bypass it.

Stack

Frontend
React 19ViteTanStack QueryTailwindRadixSchedule-X calendarhost-routed portals
Public
Astro cataloguefull-text searchTurnstileAstro landingi18n
API
Hono on Node 24modular service architectureZodBetter Authdomain events
Data
PostgreSQLDrizzlerow-level securityRedisS3 + sharp
Money & media
StripeStripe Connect payoutsvouchersLiveKitDailyKrispResendnode-cron

What it took

  • Tenant isolation is enforced by the database, not by discipline. Practice data is separated at the storage layer as well as in application code, so a mistake in a query returns nothing rather than another practice's client records.
  • One system, many jobs. Catalogue and search, booking and calendars, payments and payouts, consultations, documents, messaging and reviews — kept as one coherent codebase with a consistent shape, so a single team can carry all of it.
  • Video is a replaceable part. Consultations run through an abstraction over more than one provider, so features land everywhere at once and the provider stays a commercial decision rather than a rewrite.
  • Health data raises the floor. Consent handling, encrypted consultations, EU hosting and audit trails were requirements from the first line of code, not a compliance pass bolted on before launch.
  • Someone else can act for you. A partner or family member can use the platform on a client's behalf under their own identity, instead of the shared-password workaround most care products end up with.