Warum dein Unternehmen ein OS braucht – nicht mehr SaaS

Die Compound Startup Revolution

Etwas Fundamentales passiert gerade in der Software-Welt, das die meisten bemerken – aber noch nicht vollständig verarbeiten.

Mercury startete als Bank. Heute macht es Rechnungen, Buchhaltung, sogar Steuererklärungen. Rippling begann als HR-Software. Heute macht es IT, Payroll, Ausgabenmanagement – und greift Deel an. Stripe war Payments, jetzt ist es Billing, Invoicing, Tax, Treasury und Firmenkreditkarten. Canva war ein Design-Tool, jetzt macht es Video, Websites und Print.

Parker Conrad nennt das die Compound Startup. Sein Argument: "Mach eine Sache richtig" war eine Beschränkung – keine Strategie.

Ich denke, er hat recht. Und der Grund ist simpel: Software zu bauen war teuer. Es dauerte Jahre und Millionen, um ein gutes CRM zu bauen. Nochmal Jahre und Millionen für Buchhaltungssoftware. Man wählte eine Nische, weil man sich nicht leisten konnte, alles zu bauen.

Diese Beschränkung verschwindet gerade.

Das Fünf-Systeme-Problem

Abhi Gutgutia beschreibt das Problem perfekt:

Ein neuer Vertrag wird bei einem 40-Personen-Unternehmen unterzeichnet. Was passiert heute? Der Vertriebler geht in Salesforce, zieht den Deal auf "Closed Won", tippt den Vertragswert ein. Finance öffnet QuickBooks und erstellt manuell eine Rechnung. Legal lädt den Vertrag ins CLM-Tool. Der PM eröffnet ein Projekt in Jira. Jemand schreibt in Slack: "Acme hat unterschrieben!" – Fünf Personen haben Daten aus demselben Dokument in fünf verschiedene Systeme eingegeben. Die Hälfte davon wird leicht falsch sein.

Das ist kein Effizienzproblem. Das ist ein Architekturproblem.

Jedes dieser Systeme wurde gleich gebaut: Datenbank designen, App darauf bauen, Menschen zwingen, die Datenbank aktuell zu halten. 50 Jahre lang hat das funktioniert. Jetzt nicht mehr.

Die Datei ist die Wahrheit

Stell dir das Alternativmodell vor:

Der unterschriebene Vertrag landet im System. Das war's.

Ein Agent liest den Vertrag und leitet alles gleichzeitig ab: Deal abgeschlossen, 120.000 € jährlich, Zahlung netto-30 quartalsweise. Erste Rechnung generiert. Onboarding-Checkliste aus den Deliverables erstellt. Verlängerung in 11 Monaten markiert. Jede Abteilungssicht aktualisiert sich gleichzeitig.

Der gleiche Vertrag, den Sales wegen des Deal-Werts braucht, braucht Finance wegen der Zahlungsbedingungen, Legal wegen der Haftungsklauseln und Operations wegen der Deliverables. Heute hat jede Abteilung ein eigenes System mit einer eigenen, unvollständigen Kopie.

Im neuen Modell: Eine Datei. Verschiedene Linsen.

Warum das jetzt möglich ist

Der Grund ist ehrlich gesagt nur der Agent. Vor zwei Jahren konnte keine Software zuverlässig einen Vertrag lesen und gleichzeitig den Deal-Wert für Sales, die Zahlungsbedingungen für Finance, die Haftungsobergrenze für Legal und die Deliverables für Ops extrahieren.

Jetzt kann sie es. Das ist der Unlock. Nicht bessere Datenbanken oder bessere UIs. Besseres Verständnis von unstrukturierten, menschlich erstellten Dokumenten.

Das Company Operating System

Gutgutia nennt es ein "Company Operating System" – nicht OS im technischen Sinne, sondern die Basisschicht, die den SaaS-Stack ersetzt:

1. Deine Dateien – organisiert, als Single Source of Truth
2. Ein Agent – der alle versteht und strukturierte Daten ableitet
3. Dünne, zweckgebundene Views – für jedes Team, beliebig erstellbar und verwerfbar

Die Views sind austauschbar. Der Agent und die Dateien sind es nicht.

Wo monday.com diesen Ansatz heute schon lebt

Was an diesem Konzept spannend ist: Es ist kein reines Gedankenexperiment. Plattformen wie monday.com bewegen sich seit Jahren genau in diese Richtung – von einem Projektmanagement-Tool zu einem Work Operating System.

Die Parallelen sind frappierend:

• Eine Datenbasis, viele Views: In monday.com existiert ein Item einmal – aber Sales sieht es als Deal, PM als Task, und Finance als Budget-Position. Verschiedene Boards, Dashboards und Views auf dieselben Daten.
• Produkte als "dünne Schichten": monday CRM, monday dev, monday service – alles läuft auf derselben Plattform. Die Produkte sind die "zweckgebundenen Views" aus dem OS-Modell.
• AI als Agent-Schicht: Mit monday AI lassen sich Dokumente analysieren, Formeln generieren und Aktionen auslösen – der Anfang der Agent-Ebene, die Gutgutia beschreibt.
• Automationen als Middleware-Ersatz: Statt fünf Tools per Zapier zu verbinden, passiert alles innerhalb der Plattform. Automationen ersetzen die Copy-Paste-Arbeit zwischen Browser-Tabs.

Das ist noch nicht das vollständige File-System-First-Modell. Aber es ist die pragmatischste Annäherung, die heute existiert.

Was das für dich bedeutet

Die Frage ist nicht "Welches neue SaaS-Tool brauchen wir?" Die Frage ist: "Können wir eine Plattform finden, die als Betriebssystem für unser Unternehmen funktioniert?"

Drei konkrete Schritte:

1. Audit deinen Stack – Wie viele Tools führen Daten aus derselben Quelle? Jede Doppeleingabe ist ein Signal, dass du ein Architekturproblem hast.
2. Konsolidiere auf eine Plattform – Nicht alles auf einmal. Starte mit zwei Abteilungen, die dieselben Daten brauchen (z.B. Sales + Operations).
3. Nutze AI als Brücke – Wo du heute noch manuell zwischen Systemen synchronisierst, kann ein Agent das automatisieren. Nicht irgendwann. Jetzt.

Jedes Unternehmen versucht bereits, Daten über ein Dutzend Tools synchron zu halten. Es macht es nur schlecht – mit Integrationen, Middleware und Menschen, die zwischen Browser-Tabs kopieren.

Das Company OS macht den Sync überflüssig. Weil es nichts gibt, was synchronisiert werden muss.