SaaSpocalypse: Lohnt sich SaaS noch?

Jul 31, 2026 von Time Cockpit

Die „SaaSpocalypse“ ist eine bewusst zugespitzte Bezeichnung für eine reale Verschiebung. AI Coding Tools und Vibe Coding senken die Kosten für Softwareprototypen drastisch. Funktionen, für die Unternehmen früher zwangsläufig ein SaaS-Produkt gekauft hätten, lassen sich heute teilweise in Tagen oder Wochen nachbauen.

Damit gerät ein Teil des SaaS-Marktes zu Recht unter Druck. Ein Abonnement rechtfertigt sich nicht mehr allein dadurch, dass eine Anwendung im Browser läuft und Daten speichert. Wer nur eine austauschbare Oberfläche anbietet, wird seinen Wert in Zukunft schwerer erklären können.

Bei Zeiterfassung führt die Schlussfolgerung „Dann bauen wir sie eben selbst“ trotzdem oft in die falsche Richtung. Eine Eingabemaske ist schnell gebaut. Ein verlässliches System für Arbeitszeit, Abrechnung, Projektcontrolling, Berechtigungen, Datenschutz und Integrationen ist etwas anderes.

Aus Managementsicht ist der Kostenvergleich häufig verzerrt. Bei SaaS stehen Lizenzkosten sichtbar im Budget. Bei einer Eigenentwicklung verteilen sich die Aufwände auf Produktmanagement, Entwicklung, interne Abstimmung, Betrieb und Support. Ein Prototyp zeigt früh, was bereits funktioniert. Die langfristigen Verpflichtungen werden dagegen erst sichtbar, wenn das System produktiv genutzt wird, mehr Personen darauf angewiesen sind und die ersten Sonderfälle auftreten.

Genau das erleben wir bei Zeiterfassungsprozessen immer wieder. Auf eine zunächst einfache Anforderung folgen Fragen zu Rollen, Freigaben, abgeschlossenen Perioden, Korrekturen, Abrechnung und Auswertungen. Das spricht nicht grundsätzlich gegen Eigenentwicklung. Es zeigt aber, dass die Entscheidung nicht bei der technischen Machbarkeit enden darf. Wer selbst baut, übernimmt nicht nur den Code, sondern ein dauerhaftes internes Produkt.

Unsere zentrale These lautet deshalb:

Der faire Vergleich lautet nicht SaaS gegen AI-Prototyp, sondern dauerhaft betriebenes SaaS-Produkt gegen interne Eigenentwicklung mit vollständiger Produktverantwortung. Dieser Unterschied ist für IT-Dienstleister und professionelle Dienstleister entscheidend.

Was die SaaSpocalypse-Kritik richtig sieht

Forrester beschreibt einen Markt, in dem AI Agents etablierte Softwareabläufe verändern, nutzerbasierte Preismodelle infrage stellen und Vibe Coding das Nachbauen einzelner Funktionen erleichtert. Besonders herausfordernd werde das für horizontale SaaS-Punktlösungen mit niedrigen Wechselkosten und schwacher Einbettung in betriebliche Abläufe. Vertikale oder domänenspezifische Anbieter mit tiefer Prozesskenntnis hätten dagegen eine stärkere Ausgangsposition. Zugleich warnt Forrester davor, daraus vorschnell das Ende des betrieblichen SaaS-Kerns abzuleiten (Forrester).

Diese Unterscheidung ist wichtiger als das Schlagwort. Ein isoliertes Tool, das Daten in wenigen Feldern erfasst und wieder auflistet, kann tatsächlich austauschbar werden. Je stärker Software jedoch Regeln, Rollen, Daten und Folgeprozesse verbindet, desto weniger lässt sich ihr Wert an Screenshots oder einer Featureliste ablesen.

Für Käufer ist das eine gesunde Entwicklung. SaaS-Anbieter müssen klarer zeigen, welchen laufenden Nutzen sie stiften. Auch bestehende Verträge verdienen eine nüchterne Prüfung: Welche Prozesse hängen am Produkt? Welche Verantwortung übernimmt der Anbieter? Welche Risiken reduziert er? Und wie aufwendig wäre ein realistischer Ersatz, nicht nur ein ähnlicher Bildschirm?

Der Aha-Effekt: AI verbilligt Code, nicht Verantwortung

Um SaaS in einer AI-geprägten Welt zu bewerten, hilft aus unserer Sicht ein Modell mit drei Wertschichten.

Schicht 1: Die sichtbare Funktion

Das ist der Teil, den man in einer Demo sieht: Formulare, Tabellen, Filter, Dashboards und Workflows. Genau hier ist AI besonders stark. Sie kann Oberflächen entwerfen, Datenmodelle erzeugen, APIs anbinden und einen überzeugenden ersten Stand liefern.

Diese Schicht wird günstiger. Funktionen, die ausschließlich dort leben, werden leichter kopierbar und damit wirtschaftlich austauschbarer.

Schicht 2: Die Domänenlogik

Darunter liegt das Wissen darüber, was Daten bedeuten und wie Sonderfälle zusammenhängen. Bei Zeiterfassung betrifft das beispielsweise Arbeitszeit und Projektzeit, verrechenbare und nicht verrechenbare Leistungen, Freigaben, Korrekturen, Teilzeitmodelle, Abwesenheiten, Stichtage und Abrechnung.

Diese Logik entsteht nicht dadurch, dass ein Modell guten Code schreibt. Sie muss spezifiziert, zwischen Fachbereichen abgestimmt, getestet und über Jahre weiterentwickelt werden. Oft steckt der eigentliche Produktwert nicht im Normalfall, sondern in den vielen Ausnahmen, die im Alltag zuverlässig funktionieren müssen.

Schicht 3: Die übernommene Verantwortung

Die dritte Schicht wird in Produktdemos kaum sichtbar. Wer hält das System verfügbar? Wer spielt Sicherheitsupdates ein? Wer stellt Daten wieder her? Wer reagiert, wenn sich eine Schnittstelle ändert? Wer prüft Berechtigungen, dokumentiert Änderungen und unterstützt Anwender?

Genau hier liegt der Kern der Make-or-Buy-Entscheidung. AI kann Aufgaben in allen drei Schichten beschleunigen. Sie übernimmt aber keine Verantwortung für das Ergebnis.

Das ist aus unserer Sicht der wichtigste Effekt der SaaSpocalypse. Der Wert belastbarer Software verschwindet nicht. Er verschiebt sich von der reinen Implementierung hin zu Domänenwissen, Governance und verlässlichem Betrieb.

Warum diese Unterscheidung bei Zeiterfassung besonders wichtig ist

Eine einfache Zeiterfassungsmaske ist schnell prototypisiert: Datum, Projekt, Tätigkeit, Dauer, speichern. In einem professionellen Dienstleistungsunternehmen ist damit jedoch erst ein kleiner Teil des Problems gelöst.

Eine Korrektur zeigt die versteckte Komplexität

Nehmen wir einen unspektakulären Vorgang: Eine Mitarbeiterin korrigiert einen Zeiteintrag aus dem Vormonat.

Auf der Oberfläche ist das eine Änderung von zwei Feldern. Im Prozess stellen sich sofort weitere Fragen:

• War der Monat bereits freigegeben oder abgeschlossen?
• Ist die Leistung schon in eine Kundenrechnung eingeflossen?
• Ändert sich dadurch die Projektmarge oder Nachkalkulation?
• Muss eine Führungskraft die Korrektur erneut genehmigen?
• Wer darf den ursprünglichen und den geänderten Wert sehen?
• Bleibt nachvollziehbar, wann und warum die Änderung erfolgt ist?
• Muss die Korrektur an ein anderes System übertragen werden?

Keine dieser Fragen ist exotisch. Zusammen machen sie aus einer Eingabemaske ein betriebliches System. Genau diese Kette wird bei einem schnellen Prototyp leicht übersehen, weil der Happy Path überzeugend aussieht, lange bevor die Ausnahmen spezifiziert sind.

Ein Datensatz, viele Konsequenzen

Erfasste Zeiten können in Kundenabrechnung, Nachkalkulation, Kapazitätsplanung und Projektsteuerung einfließen. Sie helfen, Plan und Ist zu vergleichen, Überlastung sichtbar zu machen und Leistungen fair zuzuordnen. Fehler bleiben deshalb selten auf die Eingabe beschränkt. Sie erscheinen später als Rückfrage in der Buchhaltung, als unplausible Marge oder als falsche Managementinformation.

Gute Zeiterfassung sollte dabei nicht als Überwachungsinstrument verstanden werden. Für IT-Dienstleister schafft sie eine gemeinsame, möglichst verlässliche Datengrundlage. Mitarbeitende können Leistungen nachvollziehbar dokumentieren, Projektleitungen erkennen Abweichungen frühzeitig und die Geschäftsführung muss nicht ausschließlich auf Bauchgefühl vertrauen.

Arbeitszeit und Datenschutz sind keine nachträglichen Features

Der Europäische Gerichtshof hat im Urteil C-55/18 festgehalten, dass Mitgliedstaaten Arbeitgeber verpflichten müssen, ein objektives, verlässliches und zugängliches System einzurichten, mit dem die tägliche Arbeitszeit gemessen werden kann. Wie dies national konkret umgesetzt wird, ist eine eigene rechtliche Frage. Für die Systementscheidung zeigt das Urteil aber, welchen Stellenwert Verlässlichkeit und Zugänglichkeit haben (EuGH).

Zeiterfassungsdaten sind außerdem personenbezogene Daten. Artikel 25 DSGVO verlangt, Datenschutz bereits bei der Gestaltung der Verarbeitung und durch datenschutzfreundliche Voreinstellungen zu berücksichtigen. Dazu gehören geeignete technische und organisatorische Maßnahmen sowie der Grundsatz der Datenminimierung (EUR-Lex). Das ist keine Rechtsberatung, aber ein klarer Hinweis: Berechtigungen, Sichtbarkeit, Aufbewahrung und Zweckbindung gehören in die Spezifikation, nicht auf eine spätere Wunschliste.

Was AI in der Softwareentwicklung tatsächlich verändert

AI Coding ist weder bloßer Hype noch ein automatischer Ersatz für Softwareprodukte. Sie verschiebt, wo Aufwand entsteht.

McKinsey beschreibt AI in der Softwareentwicklung als tiefgreifenden Produktivitätsschub. Entscheidend ist aber die Einordnung: Erfolgreiche Organisationen verteilen nicht einfach ein Coding Tool. Sie gestalten den gesamten Entwicklungsprozess neu. AI Agents benötigen strukturierte Anforderungen, klare Akzeptanzkriterien, Architekturkontext und nichtfunktionale Erwartungen wie Sicherheit und Zuverlässigkeit. Menschen geben Richtung und Grenzen vor, prüfen Ergebnisse und verantworten Qualität (McKinsey).

Das deckt sich mit unserer praktischen Einschätzung. Je schneller Code entsteht, desto wichtiger werden Entscheidungen darüber, was gebaut werden soll, wer es prüft und wie es betrieben wird. AI kann Implementierung, Tests und Dokumentation beschleunigen. Sie ersetzt aber nicht die Abstimmung zwischen Geschäftsführung, Projektleitung, HR, Buchhaltung, Datenschutz und IT.

Auch die Produktivitätswirkung hängt stark vom Kontext ab. METR untersuchte 2025 erfahrene Open-Source-Entwickler bei Aufgaben in ihnen gut bekannten Repositories. In diesem konkreten Versuchsaufbau benötigten Entwickler mit AI-Unterstützung im Mittel 19 Prozent länger. Gleichzeitig betont METR ausdrücklich, dass daraus keine allgemeine Aussage über alle Entwickler, Werkzeuge oder Anwendungsszenarien folgt (METR).

Die Managementlehre lautet daher nicht, AI sei langsam. Produktivitätsannahmen müssen im eigenen Kontext überprüft werden. Ein schneller Prototyp beweist weder niedrigere Gesamtkosten noch ausreichende Qualität im Dauerbetrieb.

Sichere Softwareentwicklung bleibt ebenfalls ein Prozess. Das Secure Software Development Framework von NIST umfasst unter anderem die Vorbereitung der Organisation, den Schutz der Software, sichere Entwicklung und die Reaktion auf verbleibende Schwachstellen. NIST beschreibt diese Praktiken ausdrücklich als Aufgaben, die in den Entwicklungslebenszyklus integriert und kontinuierlich verbessert werden müssen (NIST).

Der faire Vergleich: Produktbetrieb gegen Produktbetrieb

Wer eine SaaS-Zeiterfassung mit einer intern erzeugten Demo vergleicht, vergleicht unterschiedliche Reifegrade. Für eine belastbare Make-or-Buy-Entscheidung müssen auf beiden Seiten dieselben Verantwortungsbereiche stehen.

Bei SaaS werden diese Aufgaben nicht automatisch gut gelöst. Sie werden aber zu prüfbaren Bestandteilen der Anbieterbewertung. Bei einer Eigenentwicklung landen sie häufig verteilt bei der internen IT und den Fachbereichen. Genau diese laufenden Aufwände und Opportunitätskosten gehören in die Rechnung. Unser Beitrag zu Make or Buy bei Zeiterfassungssystemen vertieft diese Perspektive.

Der Produktverantwortungstest für das Management

Vor der Entscheidung, eine Zeiterfassung selbst zu entwickeln, würden wir sieben Fragen schriftlich beantworten:

1. Produktverantwortung: Wer besitzt das Produkt intern und darf Anforderungen verbindlich priorisieren?
2. Kapazität: Welche feste Entwicklungs- und Wartungskapazität steht auch dann zur Verfügung, wenn Kundenprojekte drängen?
3. Betrieb: Wer trägt Verantwortung für Verfügbarkeit, Backups, Wiederherstellung und Vorfälle?
4. Governance: Wer definiert Rollen, Datenschutzregeln, Freigaben und nachvollziehbare Korrekturen?
5. Qualität: Welche Reviews, automatisierten Tests und Abnahmekriterien gelten für AI-generierten und manuell geschriebenen Code?
6. Lebenszyklus: Wer aktualisiert Abhängigkeiten und Schnittstellen in drei, fünf oder acht Jahren?
7. Ausstieg: Wie lassen sich Daten vollständig exportieren und in ein Nachfolgesystem überführen?

Wenn diese Fragen überzeugend beantwortet sind, kann Eigenentwicklung eine gute Entscheidung sein. Wenn die Antworten hauptsächlich „macht unsere IT nebenbei“ lauten, ist nicht das Coding das größte Risiko, sondern die ungeklärte Produktverantwortung.

Gerade für IT-Dienstleister sind außerdem Opportunitätskosten relevant. Die gleichen Fachkräfte könnten Leistungen für Kunden erbringen oder am eigenen Angebot arbeiten. Eine Eigenentwicklung sollte deshalb eine bewusste strategische Entscheidung für ein internes Produkt sein, nicht das Nebenprodukt eines überraschend überzeugenden Prototyps.

Wann Eigenentwicklung sinnvoll sein kann

Es wäre unseriös zu behaupten, SaaS sei immer überlegen. Ein eigenes System kann sinnvoll sein, wenn der Prozess eng begrenzt ist, echte Differenzierung schafft und dauerhaftes Produktverantwortungsvermögen vorhanden ist. Auch eine kleine interne Anwendung, die Daten aus vorhandenen Systemen zusammenführt oder einen spezifischen Arbeitsschritt automatisiert, kann mit AI sehr wirtschaftlich sein.

Die entscheidende Frage ist, wo selbst entwickelt wird. Muss wirklich der gesamte Kern neu entstehen? Oder reicht eine eigene Erweiterung, Integration oder Auswertung rund um ein etabliertes System?

Aus unserer Sicht wird die zweite Variante attraktiver. AI macht individuelle Erweiterungen günstiger, während eine Standardlösung die wenig differenzierenden, aber verantwortungsvollen Grundlagen trägt. Das ist keine Entscheidung gegen AI. Es ist eine bewusstere Arbeitsteilung.

Was eine zukunftsfähige SaaS-Zeiterfassung liefern muss

Eine SaaS-Lösung ist weiterhin sinnvoll, wenn sie drei Eigenschaften verbindet.

Ein stabiler, verlässlich betriebener Kern

Grundlegende Funktionen und Daten müssen konsistent, abgesichert und wartbar sein. Dazu gehören nicht nur Zeiteinträge, sondern auch Rollen, Korrekturprozesse, Auswertungen und der laufende technische Betrieb. Der Anbieter übernimmt Produktverantwortung und muss nachvollziehbar darlegen können, wie er sie erfüllt.

Domänenwissen statt bloßer Funktionsmenge

Für professionelle Dienstleister zählt nicht die längste Featureliste. Relevant ist, ob ein Produkt die Zusammenhänge zwischen Leistungserfassung, Projektsteuerung, Abrechnung und Arbeitszeit versteht. Domänenlogik ist besonders wertvoll, wenn sie typische Fehler verhindert und konsistente Folgeprozesse ermöglicht.

Anpassbarkeit für das eigene Geschäftsmodell

Standardisierung endet dort, wo sich Unternehmen sinnvoll unterscheiden. Projektstrukturen, Freigaben, Pflichtfelder, Auswertungen und Integrationen variieren. Eine starre SaaS-Lösung kann deshalb ebenso problematisch sein wie eine vollständige Eigenentwicklung.

Unsere Position bei time cockpit ist ein anpassbares SaaS-Produkt mit stabilem Kern. Individuelle Prozesse sollen nicht durch einen kompletten Neubau erzwungen werden. Gleichzeitig darf Anpassbarkeit nicht bedeuten, dass jedes Unternehmen Betrieb, Wartung und Grundlagen selbst übernehmen muss. Wie wir dieses Prinzip verstehen, beschreiben wir ausführlicher im Erfahrungsbericht über Anpassbarkeit in SaaS-Software.

AI passt gut in dieses Modell. Sie kann helfen, Anforderungen zu präzisieren, Erweiterungen schneller zu entwerfen oder spezifische Automatisierungen umzusetzen. Sie ist dann ein Werkzeug innerhalb eines verantworteten Systems, nicht dessen Ersatz. Wer die Eigenentwicklungsoption konkreter prüfen möchte, findet dazu unseren Beitrag Zeiterfassung selbst programmieren mit AI.

Fazit: Der Wert von SaaS wandert nach oben

Die SaaSpocalypse-Kritik stellt eine berechtigte Frage: Welchen dauerhaften Wert liefert ein SaaS-Anbieter noch, wenn AI einzelne Funktionen immer schneller erzeugen kann? Für austauschbare horizontale Tools kann die Antwort unangenehm ausfallen.

Bei Zeiterfassung entsteht der wesentliche Wert jedoch nicht allein in der Eingabemaske. Er liegt in Domänenlogik, belastbaren Daten, Datenschutz, Berechtigungen, Integrationen, Nachvollziehbarkeit, Anpassbarkeit und laufender Wartung.

AI macht diesen Wert nicht kleiner. Sie macht sichtbarer, welcher Teil eines Produkts bislang nur Implementierungsaufwand war und welcher Teil echte, laufend übernommene Verantwortung ist.

Die Managementfrage lautet deshalb nicht mehr nur „Build or Buy?“, sondern: Welche Produktverantwortung wollen wir selbst übernehmen, und für welche Verantwortung bezahlen wir bewusst einen SaaS-Anbieter?