Web-App entwickeln lassen: Scope, Technik und realistische Planung

„Wir brauchen eine Web-App” ist bei uns oft der erste Satz eines Erstgesprächs – und einer der am wenigsten aussagekräftigen. Dahinter steckt mal ein Kundenportal mit Login, mal ein internes Freigabetool für drei Personen, mal die Hoffnung, dass eine App-Idee endlich Substanz bekommt. Die Technologiewahl „Web-App” ist zweitrangig gegenüber der eigentlichen Frage: Welcher Prozess soll damit besser laufen, für wen, und was ist die kleinste Version, die das schon leistet?

Dieser Artikel gehört zum Themen-Cluster KI-Softwareentwicklung und beantwortet die Fragen, die vor der Beauftragung wirklich zählen: Wann eine Web-App die richtige Wahl ist, welche Kernfunktionen in eine erste Version gehören, wie du Auth und Rollen planst, welche Integrationen wirklich nötig sind und wie du Hosting und Wartung regelst. Er richtet sich an Geschäftsführung, Operations, IT und Fachbereich in KMU, die eine Web-App beauftragen, budgetieren oder fachlich abnehmen sollen – nicht an Entwickler:innen, die die Umsetzung selbst planen.

Das Problem: Der Scope von V1 wird nie ehrlich begrenzt

Der häufigste Grund, warum Web-App-Projekte in KMU zu lange dauern, zu teuer werden oder nie fertig wirken, ist selten die Technik. Es ist ein Anforderungskatalog, der von Anfang an mehr enthält, als für den ersten produktiven Einsatz nötig ist. Das Muster wiederholt sich: Im Kickoff-Gespräch werden nicht nur der Kernprozess, sondern gleich auch das Reporting-Dashboard, die Mobile-Ansicht, drei zusätzliche Rollen „für später” und zwei optionale Integrationen mitgeplant. Jede einzelne Anforderung klingt vernünftig. In Summe verdoppeln oder verdreifachen sie Aufwand und Zeit, bevor überhaupt geklärt ist, ob der Kernprozess in der Praxis so funktioniert wie gedacht.

Mit KI-gestützter Entwicklung hat sich dieses Muster verschärft, nicht entschärft. Eine ansehnliche Oberfläche mit Formularen, Tabellen und ein paar Diagrammen lässt sich heute in Tagen skizzieren – das erzeugt den Eindruck, das Produkt sei fast fertig. Was in dieser Geschwindigkeit selten mitwächst, ist die Substanz darunter: sauberes Rechtekonzept, belastbare Fehlerbehandlung, ein Weg für Daten aus Bestandssystemen, ein Betriebsplan nach dem Launch. Genau diese Substanz entscheidet, ob eine Web-App nach drei Monaten noch zuverlässig läuft oder zur Baustelle wird, die niemand mehr anfassen will.

Dieser Artikel löst das Problem nicht mit einer allgemeinen Checkliste „was jede Web-App braucht”, sondern mit einer klaren Grenzziehung: was in Version 1 zwingend rein muss, was bewusst draußen bleibt, und woran du das im eigenen Fall festmachst.

Begriffe kurz geklärt

Web-App bezeichnet hier eine interaktive Anwendung, die im Browser läuft, mit einem Server kommuniziert, Nutzer:innen typischerweise über einen Login unterscheidet und Daten dauerhaft speichert – im Unterschied zu einer klassischen Website, die primär Inhalte darstellt. Die Grenze ist fließend: Ein Kontaktformular macht aus einer Website noch keine Web-App; ein Kundenbereich mit Login, in dem Nutzer:innen eigene Daten sehen und bearbeiten, schon.

Native App läuft dagegen als installierte Anwendung auf einem Betriebssystem (iOS, Android, Desktop) und hat direkten Zugriff auf Gerätefunktionen wie Kamera, Push-Benachrichtigungen oder Offline-Speicher ohne Internetverbindung.

MVP (Minimum Viable Product) ist die kleinste Version eines Produkts, die eine echte Nutzenhypothese an echten Nutzer:innen prüft – eine Web-App kann, muss aber nicht als MVP gebaut werden. Wer mehr zur MVP-Logik wissen will, findet das im Cluster-Artikel zum Thema KI-MVP.

Internes Tool ist eine Web-App, deren Zielgruppe ausschließlich die eigene Belegschaft ist – meist mit geringeren Anforderungen an Design und Skalierung, aber denselben Grundanforderungen an Auth, Rollen und Betrieb. Details dazu im Cluster-Artikel zum internen Tool.

Für den Rest dieses Artikels ist mit „Web-App” gemeint: eine browserbasierte, serverseitig angebundene Anwendung mit Login und persistenten Daten, gebaut für ein KMU – egal ob für Kund:innen, Partner oder das eigene Team.

Wann ist eine Web-App passend?

Eine Web-App ist die richtige Wahl, wenn drei Bedingungen gemeinsam zutreffen: Erstens sollen mehrere Personen mit unterschiedlichen Rollen auf dieselben, sich verändernden Daten zugreifen – nicht nur Inhalte lesen, sondern etwas anlegen, bearbeiten, freigeben oder bearbeiten lassen. Zweitens soll der Zugriff plattformunabhängig funktionieren, ohne dass Nutzer:innen etwas installieren müssen – wichtig etwa bei externen Kund:innen oder Partnern, die du nicht zu einem App-Store-Download zwingen willst. Drittens ist der Anwendungsfall ohne Gerätefunktionen lösbar, die nur eine native App zuverlässig bereitstellt.

Typische Kandidaten aus der Praxis: ein Kundenportal, in dem Kund:innen Status, Dokumente oder Bestellungen einsehen; ein internes Freigabe- oder Genehmigungstool; eine Verwaltungsoberfläche für Daten, die bisher in Excel-Tabellen kursieren; ein Buchungs- oder Terminsystem mit mehreren Beteiligten.

Nicht passend ist eine Web-App, wenn eine der drei Bedingungen fehlt:

• Reine Information ohne Interaktion braucht keine Web-App, sondern eine klassische Website. Wer Öffnungszeiten, Leistungen oder Kontaktdaten zeigen will, spart mit einer Website Zeit, Geld und Wartungsaufwand.
• Ein einzelner, wiederkehrender interner Ablauf ohne mehrere Rollen ist manchmal mit einem gut konfigurierten Standardwerkzeug (Tabellenkalkulation, No-Code-Tool, Automatisierung ohne eigene Oberfläche) schneller und günstiger gelöst als mit einer eigenen Web-App.
• Gerätenahe Anforderungen – etwa dauerhafter Kamerazugriff, verlässlicher Offline-Betrieb in Gebieten ohne Netz, oder Push-Benachrichtigungen als zentrales Feature – sprechen für eine native App. Eine Web-App kann Teile davon simulieren, aber selten so zuverlässig wie eine native Lösung.

Die Entscheidung lohnt sich, bewusst zu treffen, bevor über Technik gesprochen wird – denn sie bestimmt Budget, Zeitrahmen und die Frage, wer später Betriebsverantwortung übernimmt.

Welche Kernfunktionen gehören in V1?

Die zentrale Frage für Version 1 lautet nicht „was wäre nützlich”, sondern „ohne was funktioniert der eine Kernprozess nicht”. Vier Elemente sind für praktisch jede Web-App in V1 unverzichtbar:

1. Ein durchgängiger Kernworkflow. Ein einziger Prozess, vollständig und zuverlässig abgebildet – vom Start bis zum Abschluss. Nicht drei halb funktionierende Prozesse.
2. Login mit dem nötigsten Rollenkonzept. So wenige Rollen wie möglich, aber so viele wie für den Kernprozess nötig – dazu mehr im nächsten Abschnitt.
3. Die eine Integration, ohne die nichts läuft. Wenn der Kernprozess ohne eine Anbindung an ein Bestandssystem nicht funktioniert, gehört diese Integration in V1. Jede weitere „wäre praktisch”-Integration nicht.
4. Basis-Fehlerbehandlung und sichtbare Rückmeldung. Nutzer:innen müssen erkennen, ob eine Aktion erfolgreich war, fehlgeschlagen ist oder noch läuft. Ohne diese Rückmeldung wirkt jede Web-App unfertig, selbst wenn die Kernlogik stimmt.

Bewusst draußen bleiben sollten in V1: Reporting- und Analyse-Dashboards, eine ausgefeilte mobile Ansicht über responsives Grundverhalten hinaus, Komfortfunktionen wie Bulk-Bearbeitung oder erweiterte Suche, mehrsprachige Oberflächen ohne konkreten Bedarf, und jede zweite oder dritte Zielgruppe, die „auch noch” bedient werden könnte. Diese Elemente sind nicht unwichtig – sie gehören nur auf die Liste für die zweite Ausbaustufe, nachdem der Kernprozess im echten Betrieb seine Bewährungsprobe bestanden hat.

Ein Wort zu KI-Bausteinen in der Web-App selbst: Wenn ein Teil des Kernprozesses durch ein Sprachmodell unterstützt wird – etwa automatische Kategorisierung eingehender Anfragen oder Textentwürfe –, gilt zusätzlich, was für jede KI-Komponente gilt: eine definierte Reaktion auf unsichere oder falsche Modellausgaben und Protokollierung. Das BSI stuft den Einsatz generativer KI-Modelle ausdrücklich als Quelle neuartiger IT-Sicherheitsrisiken ein, die bestehende Bedrohungen zusätzlich verstärken können, und empfiehlt dafür eine systematische Risikoanalyse als Grundlage. Für eine Web-App mit KI-Baustein heißt das praktisch: der KI-Teil ist ein Baustein im Kernworkflow, kein Freifahrtschein, Prüfschritte zu überspringen.

Wie plant man Auth und Rollen?

Auth (Authentifizierung: wer bist du) und Autorisierung (was darfst du) werden in der Praxis oft vermischt geplant – mit der Folge, dass Rechte über die Oberfläche versteckt statt tatsächlich durchgesetzt werden. Das ist die häufigste Sicherheitslücke, die ich in bestehenden Web-Apps bei Übernahme-Reviews sehe: Ein Button ist für eine Rolle ausgeblendet, die zugehörige Funktion im Hintergrund aber weiterhin über die Adresszeile oder eine API-Anfrage erreichbar.

Die OWASP Cheat Sheet Series formuliert dafür zwei Grundprinzipien, die sich direkt auf B2B-Web-Apps übertragen lassen: Least Privilege – Nutzer:innen erhalten nur die minimal nötigen Rechte – und Deny by Default – Zugriff ist standardmäßig verweigert und muss explizit erteilt werden, nicht umgekehrt. Entscheidend ist außerdem, dass Berechtigungsprüfungen serverseitig bei jeder Anfrage stattfinden, nicht nur in der Oberfläche; client-seitige Kontrollen lassen sich laut OWASP leicht umgehen und dürfen deshalb nie die einzige Absicherung sein.

Für die Rollenstruktur in V1 reicht in der überwiegenden Zahl der KMU-Fälle ein einfaches, grobes Modell:

Rollenmodell	Wann sinnvoll	Aufwand
Zwei Rollen (Admin, Nutzer:in)	Kleine Nutzergruppe, ein Kernprozess, klare Hierarchie	Gering
Drei Rollen (Admin, interne Nutzer:in, externe Nutzer:in/Kund:in)	Portale mit externem Zugriff, unterschiedliche Datensicht	Mittel
Rollenbasiert mit mehreren Abstufungen (RBAC)	Mehrere Fachbereiche, unterschiedliche Freigabeebenen	Mittel bis hoch
Attribut- oder beziehungsbasiert (ABAC/ReBAC)	Komplexe Regeln, z. B. Zugriff nur auf eigene Kund:innendaten, zeit- oder kontextabhängig	Hoch

Eigene Einordnung Philogic Labs auf Basis von OWASP-Empfehlungen und Projekterfahrung. OWASP empfiehlt für komplexe, wachsende Systeme ausdrücklich attribut- oder beziehungsbasierte Modelle gegenüber starrem klassischem RBAC – für die meisten V1-Web-Apps in KMU ist aber ein einfaches Rollenmodell (Zeile 1 oder 2) der richtige Startpunkt, nicht die Königsklasse.

Meine Faustregel aus Kundenprojekten: Beginne mit dem einfachsten Modell, das den Kernprozess sauber abbildet, und baue erst aus, wenn ein konkreter Fall im Betrieb zeigt, dass eine feinere Abstufung nötig ist. Ein zu früh gebautes granulares Rechtesystem ist eine der teuersten Formen von Over-Engineering, weil es jede spätere Änderung am Datenmodell verkompliziert.

Zur Authentifizierung selbst: OWASP empfiehlt unter anderem, auf erzwungene periodische Passwortwechsel zu verzichten und stattdessen starke Passwörter plus Multi-Faktor-Authentifizierung (MFA) zu fördern, sowie bei sensiblen Aktionen kontextabhängig erneut zu authentifizieren. Für die meisten V1-Web-Apps im B2B-Umfeld ist ein Login über einen etablierten Anbieter (z. B. Single-Sign-on über bestehende Geschäftskonten) pragmatischer und sicherer als eine komplett selbst gebaute Login-Logik – Passwort-Handling selbst zu entwickeln ist selten die richtige Investition für ein KMU.

Welche Integrationen braucht man?

Die Integrationsfrage entscheidet oft stärker über Aufwand und Zeitplan als die Web-App selbst. Meine Erfahrung: Nicht die eigentliche Oberfläche macht ein Projekt lang, sondern die Anbindung an das, was schon da ist – ein CRM, ein ERP, eine Buchhaltungssoftware, ein Zahlungsanbieter, ein bestehendes Identitätssystem.

Für V1 gilt eine einfache Prüffrage pro möglicher Integration: Funktioniert der Kernprozess ohne sie überhaupt? Wenn ja, gehört sie nicht in V1. Typische Integrationen, die diesen Test häufig bestehen (also wirklich nötig sind):

• Anbindung an das bestehende CRM oder Warenwirtschaftssystem, wenn der Kernprozess auf diesen Daten aufbaut
• Zahlungsabwicklung, wenn der Kernprozess eine Zahlung beinhaltet
• E-Mail-Versand für Benachrichtigungen, die zum Kernprozess gehören (z. B. Bestätigung, Statusänderung)
• Single-Sign-on, wenn eine bestehende Nutzerverwaltung schon existiert und ein zweites Login-System unnötige Reibung erzeugen würde

Integrationen, die den Test häufig nicht bestehen und auf die Später-Liste gehören: Anbindung an ein zweites, redundantes System „für den Fall, dass”; automatisierte Reports an ein Business-Intelligence-Tool; Synchronisation mit Werkzeugen, die nur einzelne Personen nutzen; Schnittstellen zu Systemen, die selbst noch im Umbau sind.

Jede Integration bringt zwei laufende Kosten mit, die bei der Planung oft übersehen werden: Sie kann brechen, wenn sich die Gegenseite ändert (API-Versionen, Datenformate), und sie erweitert die Fläche, auf der etwas schiefgehen kann. Für Web-Apps mit KI-Bausteinen, die automatisiert Inhalte generieren oder verarbeiten – etwa automatisch erstellte Produktbeschreibungen für eine angebundene Website –, gilt zusätzlich eine Google-Anforderung: Automatisch erzeugte Inhalte ohne erkennbaren Mehrwert für Nutzer:innen können gegen Google-Richtlinien zu massenhaftem Content-Missbrauch verstoßen, unabhängig davon, ob ein Mensch oder ein Modell sie erzeugt hat. Wer eine Integration plant, die Inhalte automatisiert nach außen gibt, sollte das von Anfang an mitdenken, nicht als nachträgliche Korrektur.

Wie regelt man Hosting und Wartung?

Der am häufigsten übersehene Teil der Planung ist nicht der Bau, sondern das, was danach kommt. Eine Web-App ist kein Produkt, das nach dem Launch „fertig” ist – Abhängigkeiten veralten, Sicherheitslücken werden bekannt, Datenmengen wachsen, das zugrunde liegende Framework bekommt Updates. Vor dem Start solltest du drei Fragen beantwortet haben:

Wer betreibt die Infrastruktur? Bei den meisten modernen Web-Apps läuft das über Cloud-Hosting mit automatisiertem Deployment – die konkrete Wahl der Plattform ist meist zweitrangig gegenüber der Frage, wer im Ernstfall Zugriff hat und reagieren kann, wenn etwas ausfällt.

Wer übernimmt Sicherheitsupdates und Monitoring? Abhängigkeiten (Bibliotheken, Frameworks) brauchen regelmäßige Updates, sonst sammeln sich bekannte Sicherheitslücken an. Monitoring sollte mindestens erkennen: Ist die Anwendung erreichbar, treten gehäuft Fehler auf, wächst die Datenmenge unerwartet. Ohne diese Grundüberwachung merkst du Probleme oft erst, wenn Nutzer:innen sich melden.

Wer behebt Fehler im laufenden Betrieb? Ob intern, extern oder über einen Wartungsvertrag mit dem Entwicklungspartner – wichtig ist, dass die Antwort feststeht, bevor der erste Fehler auftritt, nicht danach. Eine Web-App ohne benannte Betriebsverantwortung verliert erfahrungsgemäß innerhalb weniger Monate an Verlässlichkeit, unabhängig davon, wie sauber V1 gebaut wurde – Vertrauen bei den Nutzer:innen sinkt dann schneller, als es sich mit einer besseren Funktion zurückgewinnen lässt.

Bei mir läuft das in Projekten meist so: Deployment und Basis-Monitoring richte ich beim Bau der Web-App mit ein, damit Hosting von Tag eins an reproduzierbar und nicht Handarbeit ist. Wer danach den Betrieb übernimmt – das Unternehmen selbst mit geschulter interner Ressource oder eine fortlaufende externe Betreuung – ist eine bewusste Entscheidung, die ich vor dem Projektstart kläre, nicht als Frage, die sich nach dem Launch von selbst löst.

Umsetzung: So gehst du in der Praxis vor

Aus Projekten, in denen ich Web-Apps für KMU baue oder Architekturen für bestehende Vorhaben reviewe, hat sich diese Reihenfolge bewährt:

1. Den einen Kernprozess schriftlich festlegen – wer macht was, in welcher Reihenfolge, mit welchem Ergebnis. Wenn sich das nicht in wenigen Sätzen beschreiben lässt, ist der Scope noch nicht klar genug für V1.
2. Rollen so grob wie möglich planen, ausgehend vom Kernprozess, nicht von einer theoretischen Organisationsstruktur.
3. Zwingende Integrationen identifizieren mit der Prüffrage „läuft der Kernprozess ohne sie?” – alles andere auf die Später-Liste.
4. Betriebsverantwortung vor Projektstart klären, nicht als letzten Punkt vor dem Launch.
5. V1 bauen, im echten Betrieb beobachten, dann priorisiert erweitern – nicht versuchen, alle absehbaren Anforderungen vorab zu lösen.

Wenn du unsicher bist, ob dein geplanter Scope für V1 realistisch ist oder eine bestehende Architektur die nötige Rollen- und Betriebslogik mitbringt, lässt sich das im Rahmen unserer KI-Beratung einordnen – oder direkt im Erstgespräch besprechen. Scope- und Architekturfragen bei Web-App-Vorhaben gehören zu unserem Tagesgeschäft.

Risiken und Grenzen

• Ein zu breiter Scope in V1 ist das größte Projektrisiko, nicht technische Komplexität. Die meisten gescheiterten oder verzögerten Web-App-Projekte in KMU scheitern an Umfang, nicht an fehlendem Können.
• Client-seitig versteckte statt serverseitig geprüfte Rechte sind eine reale Sicherheitslücke, keine theoretische. Wer eine bestehende Web-App übernimmt, sollte das gezielt prüfen lassen.
• Fehlende Betriebsverantwortung zeigt sich nicht sofort. Eine Web-App kann Monate lang „laufen” und trotzdem unbemerkt Sicherheitslücken oder Datenprobleme ansammeln.
• Dieser Artikel ersetzt keine Rechts- oder Datenschutzberatung. Sobald personenbezogene Daten verarbeitet werden, gelten DSGVO-Anforderungen (Rechtsgrundlage, ggf. Auftragsverarbeitung, Datenminimierung), die gesondert zu klären sind. Stand: Juli 2026.
• Automatisch generierte Inhalte innerhalb der Web-App brauchen Kontrolle. Wenn ein KI-Baustein Texte oder Inhalte erzeugt, die nach außen gehen, gelten die oben genannten Transparenz- und Qualitätsanforderungen – unabhängig von der Web-App-Technologie selbst.

Kosten und Zeit: grobe Bandbreiten mit Annahmen

Belastbare pauschale Preise für „eine Web-App” gibt es nicht seriös – zu unterschiedlich sind Rollenkomplexität, Integrationstiefe und Datenmenge. Als grobe Orientierung aus eigener Projektpraxis, mit den Annahmen, unter denen sie gilt:

• Konzeption und Scope-Klärung (Kernprozess, Rollen, Integrationen): wenige Tage bis rund zwei Wochen. Annahme: Fachbereich ist verfügbar, Bestandssysteme sind bekannt und dokumentiert.
• Bau der V1-Web-App: mehrere Wochen bis wenige Monate. Annahme: ein Kernworkflow, zwei bis drei Rollen, eine bis zwei zwingende Integrationen, Standard-Cloud-Hosting.
• Laufende Wartung nach Launch: ein wiederkehrender, planbarer Aufwand für Updates und Monitoring, unabhängig vom Bau-Budget. Die genaue Höhe hängt stark von Nutzerzahl, Datenvolumen und Integrationsanzahl ab und lässt sich seriös erst nach der Konzeptionsphase beziffern.

Der stärkste Kostentreiber ist erfahrungsgemäß nicht die Oberfläche, sondern die Integrationstiefe und die Frage, wie sauber Bestandsdaten und -systeme bereits strukturiert sind. Wer vor der Beauftragung einen Festpreis für „die Web-App” nennt, ohne Kernprozess, Rollen und Integrationen vorher geklärt zu haben, hat entweder ein Standardprodukt im Angebot oder kalkuliert mit einer Überraschung für dich.

Eigenes Werkzeug: Web-App-V1-Scope-Check

Diese Tabelle nutze ich in Erstgesprächen, um den Scope einer geplanten Web-App schnell auf V1-Tauglichkeit zu prüfen:

Element	Prüffrage	In V1 oder später?
Kernworkflow	Trägt er allein schon den Hauptnutzen?	V1
Zweiter Workflow	Ist er nötig, damit Workflow 1 funktioniert?	Meist später
Rollenmodell	Reichen zwei bis drei grobe Rollen für den Kernworkflow?	V1, einfach halten
Feingranulares Rechtesystem (RBAC/ABAC)	Zeigt der reale Betrieb einen konkreten Bedarf dafür?	Später, datenbasiert entscheiden
Zwingende Integration	Läuft der Kernworkflow ohne sie?	Wenn Nein: V1
„Nice-to-have”-Integration	Läuft der Kernworkflow ohne sie?	Wenn Ja: später
Reporting/Dashboard	Wird es für den Kernworkflow selbst gebraucht?	Meist später
Betriebsverantwortung nach Launch	Ist geklärt, wer Updates, Monitoring und Fehler übernimmt?	Vor V1-Start klären, nicht verhandelbar
KI-Baustein im Kernworkflow	Gibt es eine definierte Reaktion auf unsichere Ausgaben?	Wenn Nein: vor Launch nachrüsten

Eigenes Scope-Werkzeug Philogic Labs, entwickelt aus Beratungs- und Umsetzungsprojekten; Grundlagen: OWASP-Empfehlungen zu Autorisierung, BSI-Hinweise zu generativer KI, eigene Praxis.

Checkliste: Web-App entwickeln lassen

1. Der Kernprozess ist in wenigen Sätzen beschreibbar – nicht als Liste von Funktionen, sondern als Ablauf mit klarem Ergebnis.
2. Das Rollenmodell für V1 hat maximal drei Stufen, ausgehend vom Kernprozess.
3. Berechtigungen werden serverseitig geprüft, nicht nur über ausgeblendete Buttons in der Oberfläche.
4. Zwingende Integrationen sind identifiziert, „Nice-to-have”-Integrationen bewusst auf die Später-Liste gesetzt.
5. Login basiert, wo möglich, auf etabliertem Standard (z. B. Single-Sign-on) statt komplett selbst gebauter Logik.
6. Betriebsverantwortung für Hosting, Updates und Fehlerbehebung ist vor Projektstart benannt, nicht offen gelassen.
7. Bei KI-Bausteinen im Kernprozess: Reaktion auf unsichere oder falsche Ausgaben ist definiert und protokolliert.
8. Automatisiert erzeugte Inhalte, die nach außen gehen, sind gekennzeichnet und qualitätsgeprüft.
9. DSGVO-relevante Fragen (personenbezogene Daten, Auftragsverarbeitung) sind vor dem produktiven Einsatz geklärt.
10. Reporting, erweiterte Rollen und Zusatzfunktionen sind bewusst auf eine zweite Ausbaustufe verschoben, nicht in V1 mitgeplant.

Stand: Juli 2026. Kosten- und Zeitbandbreiten sind Erfahrungswerte aus eigener Projektpraxis unter den jeweils genannten Annahmen und ersetzen keine Rechts- oder Datenschutzberatung.