Tech-Stack & Roadmap

Stadtportal-as-a-Service auf Basis von unser-wuerzburg.com — ergebnisoffene Stack-Evaluation und Produktions-Roadmap

1. Anforderungsprofil — was die Plattform können muss

Abgeleitet aus den beiden Prototypen (Richtung A „editorial“, Richtung B „Local Discovery“, je 14 Seiten), der Risikoanalyse und den B2G-Marktanforderungen ergibt sich folgendes Profil. Es treibt jede Stack-Entscheidung in diesem Report:

2. Framework-Entscheidung — ergebnisoffener Vergleich

Fünf Stack-Familien wurden ergebnisoffen gegen das Anforderungsprofil evaluiert. Die Entscheidung wurde von vier Faktoren getrieben: vorhandene Team-Expertise, EU-Hosting-Eignung (harte B2G-Anforderung), Reife des Ökosystems für Rechnungs-Billing sowie geringer Betriebsaufwand für ein kleines Team. Wo Alternativen objektiv stärker waren, ist das in die Abwägung eingeflossen — in Summe bietet jedoch kein Alternativpfad einen Vorteil, der den Verlust der vorhandenen Expertise und der EU-Hosting-Eignung aufwiegt.

3. Der Stack im Detail

3.1 Kernstack — Übersicht

Der Stack ist bewusst schlank und auf wenige, bewährte Bausteine reduziert — konkrete Produktwahl je Layer wird zum Umsetzungsstart final festgezurrt. Die Schichten im Überblick:

• Sprache & Framework: ein etabliertes PHP-Backend-Framework (Monolith) mit erstklassiger Unterstützung für strukturierte Daten-/API-Ressourcen.
• Datenbank: eine relationale Datenbank mit datenbankseitiger Mandantenisolation als zweite Verteidigungslinie.
• Cache/Queue: Cache- und Queue-Infrastruktur mit Monitoring der Hintergrundjobs.
• App-Runtime: ein Applikations-Webserver mit automatischer TLS-Zertifikatsausstellung pro Tenant-Domain; optionaler Worker-Mode ab Lastbedarf.
• Public-Frontend: ein server-gerendertes, SEO-fähiges Frontend-Framework mit Design-Tokens (Tokens der Prototypen migrierbar).
• Admin/Redaktion: ein etabliertes Admin-/Redaktions-Framework mit eingebauter Panel-Mandantenfähigkeit, CRUD/Tabellen/Formularen out of the box und einem Block-/Rich-Text-Editor.
• Suche: ein typtoleranter Such-Dienst mit Facetten und Geo-Suche (deutsche Komposita via Synonym-Wörterbuch — bekannte, pragmatisch lösbare Schwäche).
• Karten: ein DSGVO-konformer Karten- und Geocoding-Stack ohne Consent-Banner (Verkaufsargument!), self-hosted für den DACH-Raum.
• Medien: Medien-Pipeline mit AVIF/WebP-Conversions und srcset; dedizierter Bild-Proxy erst bei vielen Tenants/Formaten nötig.
• E-Mail: ein EU-Mailversand-Dienst (transaktional + Newsletter, Multi-Account → deckt Tenant-Newsletter ab).
• Auth: Authentifizierung inkl. Passkeys; optionaler SSO-Broker für Behörden-Identitäten (SAML/OIDC) ab konkretem Bedarf.
• SaaS-Billing: eigene Rechnungserzeugung mit XRechnung/ZUGFeRD — B2G zahlt per Rechnung mit Leitweg-ID; kein MoR-Anbieter kann das.
• Ticketing-Payments: ein lizenzierter Zahlungsdienstleister (PSP) mit Marktplatz-/Connect-Modell — das ZAG-Risiko (Finanztransfergeschäft) wird verlagert, Ticketgelder fließen nie über das eigene Konto; Plattform-Marge als Gebühr.
• PDF (Tickets/Rechnungen): PDF/A-3 für den ZUGFeRD-Hybrid.
• Testing/Qualität: automatisierte Test- und Qualitäts-Gates (Unit, E2E, Last, Statik) in der CI.

3.2 Multi-Tenancy-Architektur

Die wichtigste Einzelentscheidung der gesamten Plattform. Für 10–200 Tenants mit moderatem Einzeltraffic ist der 2026er-Konsens (AWS, PlanetScale, einschlägige Guides) eindeutig:

Implementierung (Defense in Depth): Mandanten-Scoping auf Applikationsebene (globale Lese-Scopes + Tenant-Middleware) als erste Verteidigungslinie; datenbankseitige Mandantenisolation pro Request als zweite — ein App-Bug kann dann kein Cross-Tenant-Leak mehr verursachen. Performance-kritisch ist eine geeignete Index-Strategie mit dem Mandanten als führendem Kriterium; richtig umgesetzt ist der Isolations-Overhead auch bei zweistelligen Millionen Zeilen vernachlässigbar. Mandantenkern: ein schlanker Mandantenkern (etabliertes, stabiles Paket oder schlanker Eigenbau), da das Single-DB-Pattern wenig Paket-Magie braucht. Einzelne „VIP-Tenants“ (Großstadt mit Sonderanforderungen) lassen sich später hybrid in eigene DBs auslagern, ohne die Architektur zu brechen.

3.3 Custom Domains & TLS pro Tenant

Jeder Tenant bringt seine eigene Domain mit (veranstaltungen.stadt-xy.de) oder nutzt eine Subdomain (stadt-xy.plattform.de). Der Self-Hosting-Weg ist hier 2026 dem Managed-Weg klar überlegen:

• Automatische TLS-Ausstellung pro Domain: Zertifikate werden on-the-fly beim ersten gesicherten Verbindungsaufbau ausgestellt — kein Vorab-Provisioning. Pflicht ist eine Domänen-Eigentumsprüfung, über die die App bestätigt „Domain gehört Tenant X“ (Missbrauchsschutz). Der gewählte Applikations-Webserver bringt dieses Feature mit — ein echtes Architektur-Argument.
• Wildcard-Zertifikat (*.plattform.de) für alle Plattform-Subdomains.
• Onboarding-Flow: Domain im Tenant-Backend anlegen → CNAME-Anleitung → automatischer DNS-Verifikations-Check → Freigabe durch die Eigentumsprüfung → Zertifikat beim ersten Request. DNS-Propagation als häufigster Support-Fall einplanen.
• Fallback bei Skalierung: ein vorgelagerter SaaS-Domain-Dienst existiert als Eskalationsoption, ist aber typischerweise US-Anbieter — bei 10–200 Domains unnötig.

3.4 Frontend-Strategie — zwei Welten, bewusst getrennt

Public-Portal (server-gerendertes Frontend-Framework): nutzt die vorhandene Frontend-Kompetenz und die Interaktionsmuster der Prototypen; das Server-Rendering liefert vollständiges HTML an Crawler — die historischen SEO-/Rendering-Schmerzpunkte sind in den aktuellen Tooling-Generationen beseitigt. Bewusste Alternative für maximale Einfachheit: rein server-gerenderte Templates für die leselastigen Seiten + interaktive Insel-Komponenten für Widgets (Karte, Checkout, Filter) — diese Entscheidung kann in Phase 1 nach einem kurzen Spike final getroffen werden; das Datenmodell ist davon unabhängig.

Admin/Redaktion (etabliertes Admin-Framework): ein vom Public-Frontend abweichender Technologie-Ansatz — das ist der bewusste Trade-off. Begründung: das Admin-Framework liefert CRUD, Tabellen, Formulare, Relation-Manager, Panel-Mandantenfähigkeit und einen Block-/Rich-Text-Editor out of the box; das von Hand nachzubauen kostet 3–4 Monate. Das Admin-Panel ist intern (Redakteure, Tenant-Admins), nicht SEO-relevant, nicht designkritisch — genau dort ist dieser Pragmatismus richtig. Die gewählte Generation ist stabil und mittelfristig ohne disruptive Major-Migration.

Headless-CMS bewusst verworfen: Die geprüften Headless-CMS-Produkte scheiden aus — mal durch Lizenzmodelle, die sich mit dem Mandantenmodell beißen, mal durch strategische Anbieter-Risiken oder Kernfeatures hinter Enterprise-Paywall bzw. restriktiver Lizenz. Keines ist SaaS-mandantenfähig out of the box; alle brächten ein zweites Laufzeit-System in den Betrieb.

3.5 Event-Datenmodell — an Standards ausrichten

Das Eventmodul ist das strategische Herzstück (vgl. Variante B der Risikoanalyse). Das interne Schema wird von Tag 1 an an offenen Standards (schema.org und etablierte Tourismus-Domain-Spezifikationen) ausgerichtet — mit strukturierten Daten für Rich Results, Kalender-Feeds und Open-Data-Schnittstellen:

• Strukturierte Daten pro Event-Detailseite (nur Einzelseiten qualifizieren für Google Rich Results — Listen nicht): Start-/Endzeit mit Zeitzone, physischer Ort, Preis/Angebot, Status für Absagen/Verschiebungen.
• Kalender-Feeds pro Tenant + pro Event (Behörden-Erwartung, UX-Standard).
• Import-/Export-Schnittstellen zu Landes- und Tourismus-Ökosystemen als reine Mapping-Aufgabe statt Umbau — und als Open-Data-Schnittstelle für Kommunen, die „offene Daten“ ausschreiben.
• Barrierefreiheits-Attribute am Venue-/Event-Modell (von den Standards vorgesehen; BITV-Kunden fragen sie ab).

4. Infrastruktur & Betrieb

4.1 Hosting-Entscheidung

Ein EU-Cloud-Hoster mit ISO/IEC 27001:2022, Datenresidenz Deutschland und AVV als Primär-Hoster — das reicht für die meisten kommunalen DMO-Vergaben. Die ehrliche Lücke: kein BSI-C5-Testat. Dafür gibt es einen dokumentierten Eskalationspfad: ein C5-zertifizierter Eskalations-Hoster (deutscher Anbieter mit C5-Testat + IT-Grundschutz, über die einschlägigen öffentlichen Beschaffungs-Broker rahmenvertraglich beziehbar) — zum ~2–3-fachen Preis, nur wenn eine Vergabe C5 hart fordert. Eine US-betriebene „Sovereign Cloud“ wäre für ein 1–3-Dev-Team Overkill und juristisch weiter umstritten.

4.2 Deployment & Tooling — Plesk wird abgelöst

Das bisherige Shared-Hosting-Panel ist kein SaaS-Betriebswerkzeug: kein Zero-Downtime-Deploy, kein Queue-Worker-Management, kein Infrastructure-as-Code — für eine SaaS mit SLA das falsche Werkzeug. Stattdessen ein schlankes, weitgehend gemanagtes Betriebs-Setup mit folgenden Funktionen:

4.3 Datenbank-Betrieb, Backup & DR

Der Primär-Hoster bietet keine native Managed-Datenbank — zwei tragfähige Wege: (a) gemanagte Datenbanken über den Provisioning-Dienst (Backups, Patching, Failover auf dem eigenen Server — der pragmatische Start) oder (b) self-managed mit dediziertem Backup-Werkzeug als späterer Ausbau. DR-Zielwerte, die in B2G-Verträgen anbietbar und mit diesem Setup realistisch sind:

Backup-Topologie: automatisierte Datenbank-Backups → S3-kompatibler Objektspeicher beim Primär-Hoster plus Offsite-Kopie zu einem zweiten Anbieter mit EU-Datenresidenz gegen Provider-Single-Point-of-Failure. Server-Snapshots als dritte Ebene.

4.4 Infrastrukturkosten — realistisch kalkuliert (netto, Stand 06/2026)

Zum Vergleich: dasselbe Setup auf einer US-betriebenen Managed-Cloud-Plattform (EU-Region verfügbar, aber US-Anbieter + Usage-Pricing) läge grob beim 3–5-Fachen und bliebe im B2G-Vertrieb angreifbar.

5. Compliance-Architektur — Recht als Produktfeature

Für B2G-Kunden ist Compliance kein Anhang, sondern Kaufkriterium. Sechs Rechtsbereiche greifen direkt ins Datenmodell und die Roadmap — alle sechs sind von Tag 1 eingeplant statt nachgerüstet:

6. Roadmap bis Production-Ready

Annahmen: 2 Entwickler Vollzeit (3. Person punktuell für Design/QA), intensiver Claude-Code-Einsatz, Prototypen A/B als Design-Grundlage vorhanden. Aufwände in Personentagen (PT) inklusive Tests — automatisierte Test- und Qualitäts-Gates laufen ab Phase 0 in CI, nicht als nachgelagerte QA-Phase. Die Phasen 1–3 sind so geschnitten, dass nach Phase 3 ein eigenständig verkaufbares Event-Modul existiert (= Variante B der Risikoanalyse als eingebauter Plan B).

6.1 Was bewusst NICHT im Scope bis GA ist

• Native Apps — PWA reicht (Check-in, Push via Web Push); native Apps erst bei nachgewiesener Nachfrage.
• Behörden-SSO als Default — erst bauen, wenn ein zahlender Kunde es fordert; Authentifizierung inkl. Passkeys deckt den Start.
• Dedizierter Bild-Proxy, Read-Replica, Multi-App-Server — vorbereitete, aber erst bei Last aktivierte Ausbaustufen.
• BundID/DeutschlandID — für ein privatwirtschaftliches Portal weder Pflicht noch offen zugänglich; nur Roadmap-Punkt, falls Tenants echte Verwaltungsleistungen integrieren.
• GraphQL — die geplanten REST-/Open-Data-Schnittstellen und strukturierten Daten decken die Open-Data-Anforderungen; GraphQL nur auf konkrete Großabnehmer-Anforderung.

7. Risiken & offene Entscheidungen

Versionsstände, Preise und Rechtslagen wurden zum Stichtag per Websuche aus den jeweiligen Primär- und Sekundärquellen erhoben (Hersteller-/Behörden-Dokumentation, Fachpresse, einschlägige Rechts- und Datenschutz-Quellen). Detaillierte Quellenangaben sind in dieser Kundenfassung nicht enthalten.