Ein Stadtwerk in Norddeutschland wollte seinen Kunden ermöglichen, Zählerstände online einzureichen, Abschläge anzupassen und Rechnungen einzusehen. Die Anforderung klingt überschaubar. Die erste Agentur lieferte ein Angebot über 12.000 Euro — für eine „Website mit Formular“. Die zweite Agentur lieferte ein Angebot über 80.000 Euro — für eine vollständige Kundenportal-Plattform. Beide hatten in gewisser Weise recht. Das Problem war, dass niemand im Vorfeld den Unterschied zwischen den beiden Ansätzen erklärt hatte.
Dieser Post erklärt ihn.
Website und WebApp: Was der Unterschied in der Praxis bedeutet
Eine Website transportiert Information. Eine WebApp verarbeitet Anfragen, speichert Daten, kennt ihre Nutzer und führt ihr gegenüber Aktionen aus.
Konkreter: Eine Website zeigt an, wann das Kundenzentrum geöffnet hat. Eine WebApp lässt den Kunden einen Termin buchen, schickt ihm eine Bestätigung, trägt den Termin ins interne Kalender-System ein und erinnert ihn 24 Stunden vorher per E-Mail.
Für Stadtwerke, Energieversorger, Telekommunikationsunternehmen und KMUs mit komplexeren Abläufen ist der relevante Bedarfsfall fast immer die WebApp — auch wenn sie oft als „Portal“ oder „Tool“ beschrieben wird. Das Marketingmaterial spricht von Digitalisierung. Was technisch geliefert werden muss, ist eine Applikation.
Die fünf Komplexitätsstufen mit realistischen Budgets
Stufe 1: Einfaches interaktives Tool (5.000–15.000 Euro)
Was das ist: Ein einzelnes, klar abgegrenztes Werkzeug — Konfigurator, Rechner, Anfrageformular mit Logik, einfaches Buchungsformular ohne Nutzerverwaltung.
Typische Beispiele: Tarifrechner für Strom oder Gas, Störungsmelder ohne Login, einfacher Terminanfrager
Was den Preis bestimmt: Frontend-Entwicklung, Backend-Logik für die eine Funktion, Hosting, DSGVO-konforme Datenübertragung
Was nicht enthalten ist: Nutzerverwaltung, Persistenz, Anbindung an Bestandssysteme
Stufe 2: WebApp mit Nutzerverwaltung (15.000–40.000 Euro)
Was das ist: Eine Anwendung, bei der sich Nutzer registrieren oder einloggen, eigene Daten einsehen und Aktionen ausführen können.
Typische Beispiele für Stadtwerke: Kundenportal mit Zählerstand-Eingabe, Rechnungsansicht, Abschlagsänderung
Typische Beispiele für KMUs: Mitarbeiterportal für Urlaubsanträge und Zeiterfassung, Kundenbereich für Auftragsübersicht
Kostenstruktur typisch:
| Posten | Kostenrahmen |
|---|---|
| Anforderungsanalyse + Konzept | 2.000–5.000 Euro |
| UI/UX Design | 3.000–7.000 Euro |
| Authentication + Nutzerverwaltung | 2.000–5.000 Euro |
| Kernfunktionen (Datenbanklogik, API) | 5.000–15.000 Euro |
| Testing + Abnahme | 1.500–4.000 Euro |
| Deployment + Dokumentation | 1.500–4.000 Euro |
Stufe 3: Plattform mit Systemanbindung (40.000–100.000 Euro)
Was das ist: Eine WebApp, die an bestehende Unternehmenssysteme angebunden ist — Abrechnungssystem, ERP, CRM, GIS oder ähnliche Backendsysteme.
Hier entsteht der größte Preissprung — nicht durch bessere Grafik, sondern durch Integrationsaufwand. Jedes angebundene System hat eigene Datenmodelle, Authentifizierungslogik und Eigentümlichkeiten. Ein Stadtwerk, das sein SAP IS-U-System, sein GIS und sein Ticketsystem in ein Kundenportal integrieren will, hat drei separate Integrationsprojekte vor sich.
Typische Anwendungsfälle: Vollständiges Kundenportal mit Echo aus dem Billing-System, Außendienstportal mit GIS-Anbindung, Bestellportal mit ERP-Rückkopplung
Was den Preis treibt:
- Qualität und Aktualität der API-Dokumentation des Bestandssystems
- Datenmigration oder paralleler Betrieb mit Altsystem
- Notwendigkeit eines Middleware-Layers bei inkompatiblen Schnittstellen
- Compliance-Anforderungen (BDEW, BSI IT-Grundschutz, ISO 27001 bei regulierten Branchen)
Stufe 4: Individuelle Enterprise-Plattform (100.000–300.000 Euro)
Was das ist: Vollständige, unternehmensspezifisch entwickelte Plattform mit mehreren Nutzergruppen, komplexen Rollen- und Rechtesystemen, Reporting und Prozessautomatisierung.
In der Energiewirtschaft: Betriebsführungsportale, Netzleitstandskommunikation, komplexe B2B-Portale für Lieferanten oder Messstellenbetreiber
Kennzeichen: Mehr als ein angebundenes Backendsystem, mehr als zwei Nutzerrollen, Auditierbarkeit aller Aktionen, Hochverfügbarkeitsanforderungen
Stufe 5: Regulierte oder sicherheitskritische Systeme (ab 300.000 Euro)
Was das ist: WebApps, die unter BSI-Anforderungen für Kritische Infrastruktur (KRITIS) fallen, eine Zertifizierung erfordern oder in sicherheitskritischen Netzsegmenten betrieben werden.
Das ist ein anderes Projektsegment mit anderem Governance-Rahmen. Stadtwerke ab einer bestimmten Versorgungsgröße sind hier betroffen. Die Kosten entstehen nicht durch besseren Code — sondern durch Dokumentationspflichten, Penetrationstests, Zertifizierungsaufwand und Betriebskonzepte.
Laufende Kosten: Was nach dem Launch kommt
Der häufigste Planungsfehler bei WebApp-Projekten ist das Unterschätzen der Betriebskosten. Eine WebApp ist kein Produkt — es ist ein laufender Betrieb.
| Kostenart | Monatlich |
|---|---|
| Hosting + Infrastruktur | 50–2.000 Euro je nach Last und Ausfalltoleranz |
| Datenbankbetrieb + Backups | 20–500 Euro |
| Sicherheits-Updates + Patches | 2–4 Stunden Entwicklerzeit/Monat |
| Monitoring + Alerting | 50–300 Euro für Werkzeuge |
| DSGVO-Dokumentation + Pflege | halbjährlicher Review einplanen |
| Weiterentwicklung | je nach Backlog |
Faustregel: Betriebskosten liegen bei 15–25 % der ursprünglichen Investitionssumme pro Jahr. Bei einer 50.000-Euro-WebApp sind das 7.500–12.500 Euro jährlich — für Hosting, Wartung, Security-Updates und minimale Weiterentwicklung.
Wer das nicht einplant, betreibt die App nach 12 Monaten auf veraltetem Stand.
Spezifische Überlegungen für regulierte Branchen
Energiewirtschaft und Stadtwerke
Kundenportale in der Energiewirtschaft unterliegen dem Messstellenbetriebsgesetz (MsbG), DSGVO-Anforderungen für Verbrauchsdaten und — bei KRITIS-relevanten Betreibern — BSI-Anforderungen für vernetzte Systeme. Das bedeutet:
- Datenhaltung in deutschen oder EU-Rechenzentren (keine US-Clouds ohne Zusatzvereinbarungen)
- Protokollierung von Zugriffen auf personenbezogene Zählerdaten
- Verschlüsselung aller Transportkanäle und gespeicherter Daten
- Regelmäßige Penetrationstests für öffentlich erreichbare Systeme
Das sind keine optionalen Features. Es sind Betriebsvoraussetzungen. Jeder Dienstleister, der ein Stadtwerk-Kundenportal entwickelt, muss diese Anforderungen kennen und einplanen.
Telekommunikationsunternehmen
Self-Service-Portale für Telko-Kunden haben ähnliche Anforderungen, ergänzt um spezifische Themen rund um Rufnummernportierung, Vertragsverwaltung und Datenschutz nach TKG. Besondere Anforderung: Auditierbare Einwilligungsverwaltung für Marketingkommunikation.
KMUs ohne regulatorischen Overhead
Für KMUs ohne Compliance-Anforderungen vereinfacht sich das Budget erheblich. Die relevante Frage ist hier: Welches Problem löst die WebApp, und was kostet das Problem heute in Personalzeit? Eine Zeiterfassungs-WebApp für 50 Mitarbeiter, die Excel-Tabellen ablöst, amortisiert sich typischerweise innerhalb von sechs Monaten — wenn sie konsequent genutzt wird.
Eigenentwicklung, Standard-Software oder Hybrid?
Nicht jede WebApp muss Eigenentwicklung sein. Für viele Standardfälle gibt es fertige Plattformen:
- Kundenportale in der Energiewirtschaft: Anbieter wie Powercloud, SAP IS-U-Portal-Module oder spezialisierte Stadtwerk-Portallösungen
- Interne Tools für KMUs: Low-Code-Plattformen wie Retool oder AppSmith für einfache Datenbankoberflächen
- Buchungs- und Terminmanagement: Cal.com (Open Source) oder spezialisierte SaaS-Anbieter
Eigenentwicklung lohnt sich, wenn die Anforderungen von keinem Standardprodukt abgedeckt werden, wenn die Integration in Bestandssysteme komplex ist oder wenn das Budget für eine Lizenzbindung langfristig ungünstiger ist als Einmalentwicklung.
Die Entscheidung sollte auf Basis einer nüchternen Total-Cost-of-Ownership-Betrachtung über fünf Jahre fallen — nicht auf Basis von Bauchgefühl.
Fazit
Eine professionelle WebApp kostet nicht „irgendwas zwischen 5.000 und 500.000 Euro“ — sie kostet genau das, was ihre Anforderungen verlangen. Das ist ein Satz, der nichts kostet, aber auch nichts erklärt.
Was hilft: Den Anforderungsrahmen sauber abzugrenzen, bevor ein Angebot eingeholt wird. Was soll die App leisten? Mit welchen Systemen muss sie kommunizieren? Wer nutzt sie, und unter welchen regulatorischen Bedingungen?
Ich arbeite seit Jahren mit Stadtwerken, Energieversorgern und mittelständischen Unternehmen an dieser Abgrenzung — bevor ein Angebot entsteht. Wenn Sie wissen möchten, in welche Komplexitätsstufe Ihr Vorhaben fällt und was das realistisch bedeutet: Sprechen Sie mich an.
