01
Native iOS und Android
Die App läuft auf modernen iPhones und Android-Geräten als native App (App Store, Play Store). Push-Benachrichtigungen, Standort, Kamera funktionieren regulär.
Technik · interne Leitplanken
Bedingungen für die Umsetzung.
Auf dieser Seite sammeln wir technische Voraussetzungen, Architektur-Prinzipien und Designentscheidungen, an denen sich die Umsetzung der einsiedeln.digital-Plattform orientieren soll. Sie ist Arbeitsgrundlage, nicht Marketing — bewusst nicht in der Hauptnavigation und nicht für Suchmaschinen indexiert.
I · Reichweite
Plattformen und Geräte
Die Plattform muss auf allen relevanten Endgeräten zuverlässig funktionieren — ohne Anbieter, Einwohnerinnen oder Gäste auszuschliessen.
02
Browser-Version (Web-App)
Alle Funktionen sind zusätzlich über den Browser zugänglich — Desktop und Mobile, ohne Installation. Wo möglich als Progressive Web App, damit auch offline-tauglich.
03
Eine Codebase
Cross-Platform-Stack (z. B. Flutter, React Native + Capacitor, oder Kotlin Multiplatform), damit drei Plattformen nicht dreifachen Pflegeaufwand bedeuten. Entscheidung steht aus, Tendenz Flutter.
Framework-Vergleich (Stand 2026)
Eine knappe Gegenüberstellung der relevanten Cross-Platform-Frameworks, die alle drei Targets (iOS, Android, Browser) aus einer gemeinsamen Codebase abdecken können. Reife-Einschätzungen sind subjektiv und beziehen sich auf den Einsatz in einem Vereins-Projekt mit kleinem Team.
↔ horizontal scrollen für alle Spalten
| Framework | Stack | Vorteile | Nachteile | Mobile | Web |
|---|---|---|---|---|---|
| Flutter | Dart · Google |
|
| hoch | mittel-hoch |
| React Native + Expo | JavaScript / TypeScript · Meta + Expo |
|
| hoch | mittel |
| Capacitor + Ionic | HTML / CSS / JS · oft mit React, Vue oder Angular |
|
| mittel | hoch |
| Kotlin Multiplatform + Compose Multiplatform | Kotlin · JetBrains |
|
| mittel-hoch | experimentell |
| .NET MAUI | C# / XAML · Microsoft |
|
| mittel | — |
| Progressive Web App (PWA, ohne Wrapper) | HTML / CSS / JS · beliebiges Web-Framework |
|
| — | hoch |
II · Architektur
Modulare Plattform
Kern-Idee: eine App, viele unabhängig entwickelbare Module. Was nicht gebraucht wird, läuft nicht. Was wächst, kann ohne Risiko ergänzt werden.
01
Module als eigenständige Einheiten
Jedes Modul (Taxi, Gastro, Marktplatz, Tourismus, etc.) ist ein abgeschlossenes Stück Software mit klar definierten Schnittstellen — eigenes Datenmodell, eigene UI-Komponenten, eigene Backend-Endpunkte.
02
Unabhängige Weiterentwicklung
Module dürfen separat entwickelt, getestet und deployed werden. Eine Modul-Aktualisierung darf andere Module nicht brechen.
- Versionierte Modul-APIs
- Klare Verträge zwischen Plattform-Kern und Modul
- Pro Modul eigene Release-Frequenz
03
API-First
Backend-Funktionalität ausschliesslich über stabile, dokumentierte APIs erreichbar. Das App-Frontend ist nur einer von mehreren möglichen Konsumenten — Drittanbieter-Integrationen oder Vereinstools können denselben Weg nutzen.
04
Plattform-Kern minimal halten
Der Kern bietet nur das, was alle Module brauchen: Authentifizierung, Berechtigungen, Navigation, Notifications, Zahlung. Geschäftslogik gehört in die Module.
05
Module zur Laufzeit nachladen — wenn die Plattform es erlaubt
Idealerweise lädt sich die App nur jene Module nach, die die Nutzer:in tatsächlich braucht. Das hält App-Grösse, Initial-Download und Speicherbedarf gering. Apple verbietet allerdings das Nachladen von nativem, kompiliertem Code (Guideline 2.5.2) — die App muss „self-contained" sein. Ausnahme: JavaScript in WebViews und JavaScript-Bundles dürfen nachgeladen werden.
- JavaScript-basierte Stacks (React Native + Expo, Capacitor / Ionic, PWA) → dynamisches Modul-Laden auf iOS möglich, ohne Store-Review pro Modul
- Nativ kompilierte Stacks (Flutter, Kotlin Multiplatform, .NET MAUI) → kein Code-Nachladen auf iOS; Module nur über reguläre App-Updates oder Server-driven UI (Konfiguration statt Code)
- Auf Android weniger restriktiv: Play Feature Delivery erlaubt „Dynamic Feature Modules" auch für Flutter und nativ
- Diese Beschränkung ist mitentscheidend bei der Framework-Wahl — siehe Hinweis bei der Vergleichstabelle weiter oben
III · Identität und Berechtigungen
Wer darf was sehen, wer darf was tun
Berechtigungen sind nicht „eingeloggt ja oder nein", sondern ein feingranulares System, das die modulare Struktur respektiert.
01
Single Sign-On für alle Module
Eine Identität, ein Login, Zugriff auf alle Module gemäss Rolle. Kandidaten: ZITADEL (Schweiz, Open Source), Authentik, Keycloak, oder eine selbst gehostete Lösung.
02
Rollen und Permissions pro Modul
Jedes Modul definiert eigene Rollen (z. B. „Restaurant-Inhaber", „Lieferfahrer", „Gast"). Berechtigungen sind kombinierbar — eine Person kann gleichzeitig Gewerbe-Anbieter und Endkunde sein.
- Rollen feingranular: Lesen / Schreiben / Verwalten getrennt
- Anbieter:innen sehen nur ihre eigenen Daten
- Vereins-Admins können Modul-Konfigurationen verändern, aber nicht Geschäftsdaten der Anbieter
- Auditing: jede sicherheitskritische Aktion wird protokolliert
03
Privatsphäre der Endnutzer:innen
Wer als Einwohner:in oder Gast die App nutzt, kann das ohne Pflicht-Konto. Funktionen ohne Login wo immer möglich; Login nur wenn Bestellung, Reservation oder personalisierte Inhalte erforderlich sind.
IV · Daten und Datenschutz
Datenhoheit und Sicherheit
Die Plattform verarbeitet sensible Daten — Adressen, Bestellungen, Standorte. Sicherheit und Datenschutz sind nicht optional.
01
Hosting in der Schweiz
Personendaten werden vorzugsweise auf Servern in der Schweiz oder bei nachweislich DSG-konformen europäischen Anbietern verarbeitet. Keine US-Cloud-Provider für Personendaten.
02
Verschlüsselung
Transportverschlüsselung (TLS 1.3) durchgängig. Datenbanken verschlüsselt at-rest. Sensible Felder (z. B. Telefonnummern) zusätzlich anwendungsseitig.
03
Datenminimierung
Es werden nur jene Daten erhoben, die für den jeweiligen Zweck nötig sind. Kein Tracking, keine Profilbildung, keine Werbe-IDs.
04
Auftragsbearbeitung sauber
Mit jedem Dienstleister (Hosting, Payment, Mail) wird ein Auftragsbearbeitungsvertrag (AVV) geschlossen. Verzeichnis der Bearbeitungstätigkeiten geführt.
V · Qualität und Betrieb
Was den Code zusammenhält
01
Open-Source-First
Wo bewährte Open-Source-Bausteine existieren, werden sie verwendet (Bestellsystem, Reservation, Karten, Auth). Eigener Code wird nach Reifephase als Open Source freigegeben — Lizenz noch zu wählen, Tendenz AGPL oder MIT.
02
CI / CD und automatisierte Tests
Jede Änderung läuft durch automatisierte Tests, bevor sie in Staging oder Production landet. Deployments sind Knopfdruck — nicht Heldentat einzelner Personen.
03
Monitoring und Observability
Zentrale Logs, Metriken und Tracing. Bei Störungen wird das verantwortliche Modul-Team informiert; bei Sicherheitsvorfällen die Vereinsleitung.
04
Accessibility (WCAG 2.1 AA)
Die App muss von Menschen mit Sehbeeinträchtigung, eingeschränkter Motorik oder kognitiven Einschränkungen nutzbar sein. Screenreader, Tastaturbedienung, ausreichender Kontrast — kein Add-on, sondern Pflicht.
05
Mehrsprachigkeit (i18n)
Deutsch als Hauptsprache, alle UI-Texte mit i18n-Framework verwaltet. Englisch in der zweiten Phase. Für Tourismus-Module später Französisch und Italienisch.
06
Performance
Mobile First. Time to Interactive unter 3 Sekunden auf Mittelklasse-Smartphones, kalter Start unter 2 Sekunden. Code-Splitting nach Modulen, Bilder lazy.
VI · Skalierung und Zukunft
Über Einsiedeln hinaus
01
Multi-Mandanten-fähig
Eine Codebase, mehrere Vereine in mehreren Regionen — jeder mit eigener Konfiguration, eigenem Branding, eigenen aktivierten Modulen. Datentrennung pro Mandant ist Pflicht, nicht Empfehlung.
02
Konfiguration vor Customizing
Was Regionen voneinander unterscheidet (Logo, Farben, Module, Inhalte), wird über Konfiguration gesteuert. Code-Forks vermeiden — sie zerstören die Skaleneffekte.
03
Schnittstellen statt Insellösungen
Wo bestehende Systeme existieren (Tourismus-CRM, Gemeinde-Software, Reservationssysteme), gibt es Schnittstellen statt Doppelerfassung.
04
Exit-Strategie
Falls die Software-Gesellschaft (Ebene 2 der Struktur) ausfällt, sichert eine Quellcode-Escrow-Regelung den Zugriff. Daten exportierbar, niemand wird auf der Plattform „eingesperrt".
VII · Entwicklungs-Modell
Wie wir bauen
01
KI-augmentierte Entwicklung
Moderne KI-gestützte Coding-Werkzeuge (Claude Code, Cursor, Copilot) sind integraler Bestandteil des Entwicklungs-Stacks. Sie ersetzen niemanden, sie machen jede:n schneller. Verantwortung für Code, Architektur und Tests bleibt bei Menschen.
02
Trunk-based Development
Kleine, häufige Änderungen direkt in den Hauptzweig — keine langlebigen Feature-Branches. Feature-Flags trennen Deployment von Release.
03
Pair- und Mob-Programming bei kritischen Stücken
Sicherheits-, Berechtigungs- und Zahlungs-Code wird nie von einer Person allein geschrieben. Vier-Augen-Prinzip ist nicht verhandelbar.
04
Dokumentation als Code
Architektur-Entscheide werden als Markdown-Dokumente im Repo geführt (ADRs). Diese Seite hier ist Beispiel: lebendes Dokument, versioniert, durch alle einsehbar.
VIII · Recherche · Authentifizierung
Identity Provider und Rechte-Modell
Die Anmeldung muss einheitlich für alle Module funktionieren (Single Sign-On), modul-spezifische Rollen abbilden, MFA und idealerweise Passkeys unterstützen und auf einem Identity-Provider laufen, dem wir vertrauen können — am liebsten mit Schweizer oder europäischer Trägerschaft. Diese Sektion sammelt die aktuell evaluierten Optionen.
Vergleich der Optionen
↔ horizontal scrollen für Kosten und Pro/Con
| Lösung | Stack | Herkunft | Hosting | Kosten / Monat | Vorteile | Nachteile |
|---|---|---|---|---|---|---|
| Zitadel | Go · Open Source | 🇨🇭 Schweiz (Zitadel AG) | SaaS Schweiz oder Self-hosted | SaaS: Free bis 25k Auth-Requests/Mo · Pro ab USD 100/Mo · Self-hosted CH: ~CHF 60–100/Mo |
|
|
| Keycloak | Java · Open Source | 🇪🇺 EU-Wurzeln (Red Hat / Community) | Self-hosted überall, auch in der Schweiz | Lizenz frei · Self-hosted CH: ~CHF 70–120/Mo (Java braucht 4 GB RAM für komfortablen Betrieb) |
|
|
| Authentik | Python · Open Source | 🇩🇪 Deutschland (Authentik Security GmbH) | Self-hosted oder SaaS (EU) | Open Source frei · Enterprise SaaS auf Anfrage · Self-hosted CH: ~CHF 60–100/Mo |
|
|
| Ory (Kratos + Hydra + Keto) | Go · Open Source | 🇩🇪 Deutschland (Ory Corp) | Self-hosted oder Ory Network (EU/US) | Self-hosted CH: ~CHF 80–140/Mo (mehrere Services) · Ory Network: ab USD 250/Mo (Pro) |
|
|
| Authelia | Go · Open Source | 🌍 Internationale Community | Self-hosted | Lizenz frei · Self-hosted CH: ~CHF 30–50/Mo (sehr leichtgewichtig) |
|
|
| Selbst gebaut (eigenes Auth-System) | — | — | — | Einmalig CHF 30–60k Entwicklung · laufend CHF 1.5–3k/Mo (Wartung) + ~CHF 5–10k/Jahr Pen-Tests |
|
|
Rechte-Modell · User × Modul × Berechtigung
Die Anforderung: jeder Nutzer wird einem oder mehreren Modulen zugeordnet, jedes Modul definiert eigene Rollen mit eigenen Berechtigungen. Die Klassen-Modelle dafür:
01
RBAC (Role-Based Access Control)
Klassisches Modell: Nutzer:in bekommt eine oder mehrere Rollen, jede Rolle hat zugeordnete Berechtigungen. Pro Modul werden eigene Rollen definiert (z. B. „Restaurant-Inhaber" im Gastro-Modul, „Vereinsadmin" im Vereins-Modul).
Bewertung: Passt sehr gut zu unserem Vorhaben. Einfach zu verstehen, gut etabliert. Nachteil: bei sehr vielen Rollen-Kombinationen wird es unübersichtlich.
02
ABAC (Attribute-Based Access Control)
Berechtigungen ergeben sich aus Attributen von Nutzer:in, Ressource und Kontext (z. B. „Anbieter:innen dürfen nur eigene Bestellungen lesen, wenn Status nicht abgeschlossen"). Sehr flexibel, aber komplex.
Bewertung: Ergänzend einsetzbar wo RBAC nicht reicht — z. B. zeitlich begrenzter Zugriff auf einzelne Module. Sollte nicht das primäre Modell sein.
03
ReBAC / Zanzibar (Relation-Based)
Berechtigungen modelliert über Relationen: "User X ist Inhaber von Restaurant Y", "Restaurant Y gehört zu Modul Gastro". Sehr mächtig für komplexe Hierarchien (Google nutzt dieses Modell intern). Implementierungen: Ory Keto, OpenFGA, SpiceDB.
Bewertung: Ideal, wenn Berechtigungen über mehrere Module quervernetzt werden — z. B. „Verein-Admin sieht alle Module, Modul-Verantwortliche nur ihres". Etwas Overkill für den Start, aber zukunftsfähig.
IX · Recherche · Hosting
Schweizer Hosting für Cluster-Betrieb
Sobald die App-Plattform startet, brauchen wir mehr als einen einzelnen Coolify- Server. Realistisch reden wir von einem kleinen Kubernetes-Cluster mit drei bis sechs Worker-Knoten plus einer Datenbank, Object Storage und (idealerweise) managed Postgres. Diese Sektion vergleicht die wichtigsten Schweizer Cloud- Anbieter und schätzt die laufenden Kosten für zwei Szenarien.
Setup-Szenarien
Single-Server
1 VM mit Coolify oder k3s · alle Module + Postgres + Redis im selben Container-Stack · ideal für die ersten 6–12 Monate.
Last: bis ~500 MAUKleiner K8s-Cluster
3 Worker-Knoten + managed (oder eigener) Control Plane + dedizierte Postgres + Object Storage · redundant, skalierbar, modular deploybar.
Last: ~2 000 MAU / 1 000 DAUHochverfügbar
6+ Worker, Multi-AZ, Postgres-Cluster mit Replikation, dedizierter Monitoring-Stack · erst relevant ab grossem Mitgliederbestand oder mehreren Regionen.
Aktuell nicht im FokusSchweizer Cloud-Anbieter im Vergleich
↔ horizontal scrollen für Setup-Details, Pro/Con
| Anbieter | Standort | K8s-Angebot | Setup-Beispiele | Kosten / Monat | Vorteile | Nachteile |
|---|---|---|---|---|---|---|
| Cloudscale.ch | 🇨🇭 Bern · 100 % Schweiz | Kein managed K8s — VMs, K8s self-managed (z. B. k3s, Talos) |
| MVP ~CHF 50/Mo · Cluster ~CHF 130–170/Mo |
|
|
| Exoscale | 🇨🇭 Lausanne (+ EU-Zonen) · A1 Telekom Austria Group | SKS — Scalable Kubernetes Service (managed, Control Plane gratis) |
| MVP ~CHF 30/Mo · Cluster ~CHF 140–200/Mo |
|
|
| Infomaniak Public Cloud | 🇨🇭 Genf · 100 % Schweiz | Kubernetes Service auf OpenStack (managed, Beta seit 2023, produktiv seit 2024) |
| MVP ~CHF 15/Mo · Cluster ~CHF 100–160/Mo |
|
|
| Init7 / V-Server | 🇨🇭 Winterthur · 100 % Schweiz | Kein managed K8s — V-Server / Bare Metal, alles self-managed |
| MVP ~CHF 20/Mo · Cluster ~CHF 100–140/Mo |
|
|
| 🇩🇪 Vergleichswert · aktuell genutzt für Webseite und Workflows | ||||||
| Hetzner | 🇩🇪 Falkenstein/Nürnberg · DE Cloud | Kein eigenes managed K8s, aber Hetzner Cloud Volumes + LB integriert |
| MVP ~CHF 4/Mo · Cluster ~CHF 30–60/Mo |
|
|
Etwas fehlt? Etwas falsch eingeschätzt?
Diese Sammlung lebt von kritischer Prüfung. Wenn du Erfahrung in Architektur, DevOps, Datenschutz, Mobile-Entwicklung, Auth, Accessibility oder Multi-Tenant-SaaS mitbringst und etwas siehst, das ergänzt, geschärft oder gestrichen gehört — schreib uns.