Alles als Code: Wie man ein Unternehmen mit einem einzigen Monorepo betreibt

 (kasava.dev)
3 Punkte von GN⁺ 2026-01-01 | 1 Kommentare | Auf WhatsApp teilen
  • Kasava verwaltet den gesamten Produktentwicklungsprozess in einem einzigen Monorepo und integriert dabei Code, Dokumentation, Marketing und Betriebsdaten
  • Alle Änderungen werden in einem einzelnen Commit abgebildet, sodass Backend, Frontend, Website und Dokumentation gleichzeitig aktualisiert werden
  • AI-Tools greifen direkt auf Code, Dokumentation und Website zu, um Konsistenzprüfungen, automatische Dokumentationsaktualisierungen und Content-Reviews durchzuführen
  • Mit CLAUDE.md, Selective CI/CD und einer unabhängigen npm-Projektstruktur wird die Komplexität großer Repositories minimiert
  • Dieser Ansatz stärkt eine AI-native Entwicklungskultur und beseitigt die Grenzen zwischen Produkt, Content und Betrieb, was schnelle Deployments und Zusammenarbeit ermöglicht

Bedeutung von AI-nativer Entwicklung und Monorepo

  • Kasava integriert alle Plattformbestandteile in einem einzigen Git-Repository und umfasst nicht nur Code, sondern auch Dokumentation, Marketing, E-Mails und Investorenunterlagen
    • Beispiele: frontend/, backend/, website/, docs/, marketing/, external/ sowie mehr als 5.470 TypeScript-Dateien
  • AI greift gleichzeitig auf Code und Dokumentation zu und ermöglicht kontextbasierte Automatisierung
    • Dokumentationsänderungen, Preisänderungen auf der Website und Blog-Validierung werden in einer einzigen AI-Konversation verarbeitet
  • Alle Änderungen werden über denselben Git-Workflow (git push) deployt
    • Code, Inhalte, Dokumentation und Marketing durchlaufen dieselben Review-, CI/CD- und Audit-Prozesse
  • Dieser Ansatz erhöht Geschwindigkeit und Konsistenz und etabliert eine Kultur, in der „alles als Code verwaltet“ wird

Warum alles in einem Repository zusammenführen?

  • Atomare Änderungen über Grenzen hinweg (Atomic Changes)
    • Bei Änderungen an einer Backend-API werden Frontend-Typdefinitionen und Dokumentation im selben Commit aktualisiert
    • Beispiel: Beim Hinzufügen einer Asana-Integration werden Backend, Frontend, Dokumentation und Website in einem PR zusammengeführt
  • Single Source of Truth
    • Mit einer einzigen billing-plans.json werden Tarifgrenzen definiert, auf die alle Services verweisen
    • AI prüft automatisch die Konsistenz zwischen Backend, Frontend und Website
  • Projektübergreifendes Refactoring
    • In der IDE lassen sich Code, Dokumentation und sogar Blog-Beispiele repositoryweit durchsuchen und bearbeiten
  • Gemeinsame Tools und Pipelines
    • Gemeinsames CI/CD, Abhängigkeiten und Suchumgebung vereinfachen die Verwaltung

Repository-Struktur und Komponenten

  • Core Application:
    • frontend/ basiert auf Next.js 16 + React 19, backend/ nutzt Cloudflare Workers + Hono + Mastra
    • Bei API-Änderungen werden Typsicherheit und Test-Utilities gemeinsam genutzt
  • Marketing:
    • Enthält website/, marketing/blogs/, investor-deck/, email/
    • Blogs, E-Mails und Investorenmaterialien werden alle als Code versioniert und können per git revert zurückgesetzt werden
  • Documentation:
    • docs/ ist die öffentliche Dokumentation auf Basis von Mintlify, docs-internal/ enthält interne Architekturdokumente
    • Zusammen mit dem Code durchsuchbar und statt eines Wikis stets in Echtzeit aktuell
  • External Services:
    • Umfasst externe Deployment-Services wie Chrome-Erweiterung, Google Docs Add-on und GCP Functions
    • Durch gemeinsame API-Verträge werden Änderungen gleichzeitig übernommen
  • Development Infrastructure:
    • Enthält Mock-Server und Test-Tools für die lokale Entwicklung wie github-simulator/, infra-tester/, scripts/

Betriebsweise und Entwicklungskultur

  • Keine Workspaces
    • Jedes Verzeichnis bleibt ein eigenständiges npm-Projekt, um Abhängigkeitskonflikte zu vermeiden
  • Selective CI/CD
    • GitHub Actions werden pfadbasiert ausgelöst, sodass nur relevante Tests ausgeführt werden
  • CLAUDE.md-Regeln
    • In jedem wichtigen Verzeichnis werden Tech-Stack, Befehle und Architekturentscheidungen dokumentiert
    • AI-Assistenten lesen diese Informationen, um den Projektkontext zu verstehen
  • Konsistente Tool-Konfiguration
    • Gemeinsame Einstellungen wie .prettierrc, .eslintrc, tsconfig.json bleiben einheitlich

Herausforderungen und Gegenmaßnahmen

  • Repository-Größe: Der aktuelle Clone dauert etwa 20 Sekunden, Git zeigt keine Performance-Probleme
    • Große Assets sollen künftig in R2/S3 ausgelagert werden
  • Build-Zeit: Jedes Projekt wird unabhängig gebaut, mit schnellen Rebuilds durch Turbopack, Wrangler und WXT
  • Berechtigungsgrenzen: Kleine Teams haben Vollzugriff, bei Bedarf lassen sich CODEOWNERS und Branch Protection einsetzen
  • Kontextwechsel: Der Wechsel zwischen verschiedenen Sprachen (TypeScript, Apps Script, MJML) wird durch CLAUDE.md und einheitliche Formate erleichtert

Fazit

  • Kasavas Monorepo ist nicht nur ein Trend, sondern ein Werkzeug zur Maximierung der Produktivität durch Kontextintegration
  • Backend, Frontend, Dokumentation und Marketing arbeiten in einer einzigen Änderung zusammen, und AI validiert dies in Echtzeit
  • Dadurch fungiert das „Monorepo“ letztlich nicht als Einschränkung, sondern als Beschleuniger (force multiplier)

Verwandte Beiträge

1 Kommentare

 
GN⁺ 2026-01-01
Hacker-News-Kommentare

  • Das wirkt nicht wie die Verwaltung eines ganzen Unternehmens, sondern eher nur wie ein einziges Produkt (Monorepo)
    Dinge wie Finanzen, HR, Verträge oder Teamfotos fehlen, es ist im Grunde nur eine Frontend-+Backend-Struktur, in die etwas ungewöhnlich noch ein Marketing-Ordner aufgenommen wurde

    • Im verlinkten Beitrag sieht man, dass dieses Unternehmen faktisch ein Ein-Personen-Unternehmen ist
      Deshalb ist es möglich, alles in ein einziges Repo zu packen, aber dann stellt sich die Frage nach dem Wert der daraus gewonnenen „Erkenntnisse“
    • „AI! AI!“
    • Im Repo ist auch kein Infrastruktur-Code (IaC) enthalten
    • Ich würde gern ein Beispiel sehen, in dem wirklich alles in einem GitHub-Repo liegt
      Zum Beispiel sogar verschlüsselte Artefakte, nach dem Muster „Nur der CEO besitzt den Schlüssel physisch“
      Es wäre schön, wenn GitHub ein Konzept für private Ordner hinzufügen würde, aber das ist wohl ein ACL-Thema und vielleicht zu viel verlangt

  • Ich unterstütze die Philosophie von Monorepo und keinem Development-Branch
    Aber Entwicklung und Release sollten getrennt sein
    Man sollte stabile Releases abzweigen und per Cherry-Pick Änderungen übernehmen können, und die API-Stabilität zwischen Frontend und Backend muss unbedingt gewahrt bleiben

    • Manche fragten auch, was „kein Development-Branch“ eigentlich bedeutet
      Wenn direkt auf dem Main-Branch entwickelt wird, interessiert sie, wie man parallel laufende Arbeiten unterschiedlicher Größe organisiert
    • Andere fragten nach konkreten Fällen, in denen Cherry-Pick nötig ist
      Sie betreiben selbst mehr als drei Produkte in einem Monorepo und hatten auch mit Deployment pro stabilem Release keine Probleme
    • Jemand sagte, er steuere den Zeitpunkt des Deployments mit Feature Flags
    • Eine andere Person mag es, alte Branches beizubehalten
      Sie mag kein Git Squash und sagt, ein Forking-Modell gebe Entwicklern mehr Freiheit

  • Die Aussage „Eine einzige Änderung aktualisiert alles gleichzeitig“ ist eine gefährliche Illusion
    In Systemen mit DB oder APIs muss man immer an Abwärtskompatibilität denken
    In Organisationen mit mehreren Teams kommt es vor, dass ein Team ein Upgrade nicht validieren kann und dadurch alle anderen ausbremst
    Deshalb ist ein schrittweiser Rollout unverzichtbar

    • Stimme voll zu. In einem kleinen Unternehmen (Kasava) mag das funktionieren, aber bei globalem SaaS sind schon ein paar Minuten Downtime kritisch
      Das Monorepo an sich ist nicht schlecht, aber „eine Änderung und alles wird sofort deployed“ ist unmöglich
      Denn DB-Schema und Code können nicht gleichzeitig geändert werden
      Solche Texte wirken wie ein von AI geschriebener Blog, und es sieht nicht so aus, als gäbe es viele echte Kunden
    • Es gab auch den Einwand, dass der Ort, an dem Code gespeichert wird (Repo), und die Art des Deployments getrennt betrachtet werden sollten
      Man solle Organisationsprobleme nicht mit technischen Problemen verwechseln, sondern sie durch teamübergreifende Richtlinien und Leadership koordinieren
    • Jemand sagte, er nutze ein Monorepo zusammen mit automatischer Codegenerierung (openapi-generator), um API-Änderungen zwischen Services sofort abzubilden
      Er ergänzte, dass dieser Ansatz nur mit einem kleinen Team praktikabel sei
    • Auf die Aussage, der Vorteil liege darin, AI-Kontext an einem Ort zu bündeln, meinten andere, man könne auch einfach mehrere Repos als Workspace klonen
    • Umgekehrt gab es die Meinung, dass es noch schlimmer sei, wenn alle Services ihre eigenen Versionen behalten und nie aktualisieren

  • Früher mochte ich Monorepos nicht, aber mit Claude Code hat sich meine Meinung geändert
    Wenn Frontend und Backend in einem Repo liegen, ist die Synchronisierung einfacher

    • Auch wenn man Claude im übergeordneten Verzeichnis öffnet, funktioniert es gut, aber der Vorteil sei, beide Seiten mit einem einzigen Commit gleichzeitig zu ändern
    • Es gab auch die Reaktion: „Wenn der Grund für ein Monorepo nur darin besteht, ein paar Command-Flags zu sparen, ist das schon etwas albern“
    • Ich habe ebenfalls auf ein Monorepo refaktoriert, weil es schwer war, mehrere LLM-Tools miteinander zu verbinden
    • Wegen der Hoisting-Probleme von React Native vermeide ich Yarn Workspaces, aber PRDs oder Planungsdokumente im Repo zu haben, war nützlich, um AI Kontext zu geben
    • Claude Code kann tatsächlich mehrere Verzeichnisse gleichzeitig handhaben, daher ist ein Monorepo nicht zwingend nötig

  • Dieser Text fühlt sich an, als wäre er von AI geschrieben
    Es ist ermüdend, weil sich kaum noch von Menschen geschriebene Inhalte finden lassen

    • Lässt man ihn durch GPTZero laufen, wirkt fast alles AI-generiert
      Sätze wie „This isn’t just for…“ oder „The Challenges (And How We Handle Them)“ sind typischer AI-Tonfall
    • Andere meinten dagegen, sie seien es leid, ständig Beschwerden über AI-Texte zu lesen
      Selbst wenn sie nicht perfekt seien, seien sie doch besser als von Menschen geschriebene Texte

  • Die Stelle, an der man „Claude sagt, es solle die Preisseite aktualisieren“, wirkt seltsam
    Wenn man die Marketing-Seite im selben Repo verwaltet, ist schwer nachvollziehbar, warum man das einem LLM überlässt, obwohl es doch reichen würde, einfach Daten aus einer Config-Datei zu lesen

    • Es gab den Hinweis, dass AI zu einer Sucht oder Abhängigkeit werde
    • Dem wurde entgegengehalten: „Code Review gibt es immer noch“
      Nur weil AI genutzt wird, heißt das nicht, dass Menschen nichts mehr prüfen

  • Es wirkt verwirrend, Frontend, Backend und Website in ein einziges Repo zu legen
    Eine Vereinheitlichung auf Commit-Ebene klingt gut, aber mit drei Repos lässt sich das ebenfalls ausreichend verwalten
    Ein Monorepo richtig zu betreiben, verursacht erhebliche laufende Kosten

  • Der Text wirkt zwar AI-generiert, aber die Idee, IaC extrem auszuweiten, ist an sich interessant
    Deshalb sind die Gefühle dazu gemischt

    • Erstaunlich ist, dass die meisten Kommentare die AI-Spuren gar nicht erkannt haben
      Wenn sich dieser LLM-Stil künftig in der breiten Öffentlichkeit etabliert, werden heutige Texte vermutlich altmodisch wirken
    • Manche meinten auch, schon Formulierungen wie „Why This Matters“ hätte man besser ändern sollen
    • Andere sagten, AI-Nutzung nicht offenzulegen und den Text unter einem menschlichen Namen zu veröffentlichen, wirke wie intellektuelle Unredlichkeit

  • Wenn die Unternehmenswebsite im selben Repo liegt, findet man Branding-Materialien und Tonalität leicht wieder
    Dadurch wird es einfacher, kundenorientierte Slides oder Demo-Videos automatisch zu erzeugen
    Darüber hinaus ist auch die Idee interessant, Dokumentation, Bugs und Issues an einem Ort zu bündeln

  • Beim früheren Startup Pangea wurde eine ähnliche Struktur aufgebaut
    Insgesamt war das gut, aber nicht perfekt

    • Der Versuch, alles über das Repo zu verwalten, machte Änderungen an Feature Flags langsam, und die Pflege unveränderlicher Branches war schwierig
    • Als es etwa 20 Services wurden, wurde GitLab CI langsam und komplex
    • E2E-Tests waren langsam und instabil, sodass die Pipeline oft kaputtging
      Trotzdem gab es auch Erfolge wie den Wechsel auf ARM und damit 70 % weniger Compute-Kosten
      Pangea-Link
    • Daraufhin fragte jemand, ob sie Monorepo-Tools wie turbo, buck oder Bazel verwendet hätten
      Ohne solche Tools stoße man bei der Skalierbarkeit von CI schnell an Grenzen