Ich bin Solo-Entwickler. Ich habe fünf Produkte live: CDL und Eduvivo für Bildung, Worklino für KMU, Cavallearn für Reitsport, ThinkLab für MINT-Stationen. Dazu MaderStudio.Web als Holding-Seite.
Sechs Hosts, eine Codebase, ein Entwickler. Wenn ich das Leuten erzähle, ist die häufigste Reaktion: "Das kannst du nicht ernst meinen."
Doch. Und ich erkläre warum.
Microservices wären für mich eine Katastrophe
Microservices sind ein großartiges Muster — wenn du fünf Teams hast, die unabhängig deployen müssen. Ich habe ein Team von einer Person. Für mich würden Microservices bedeuten: fünf Pipelines pflegen, fünf Mal Authentifizierung debuggen, fünf Mal Logging-Infrastruktur. Mehr Infrastruktur als Produkt.
Separate Repos sind die zweitschlechteste Idee. Jeder Bugfix in der Benutzerverwaltung müsste fünfmal kopiert werden. Jedes Update am Auth-System fünfmal getestet. Nach drei Monaten driften die Kopien auseinander, und der Code wird zur Schuldnerverwaltung.
Was Reitsport und Handwerk gemeinsam haben
Auf den ersten Blick: nichts. Eine Plattform für Sitz-Analyse mit AI-Pose-Estimation und eine Plattform für Handwerker-Rechnungen sehen aus wie zwei verschiedene Universen.
Unter der Haube teilen sie 80 Prozent ihres Codes. Beide brauchen Benutzerkonten, Rollen, Organisationen, Rechnungen, Datei-Storage, Notifications, OAuth-Login. Wenn ich diese Bausteine sauber als Module baue, kann jedes Produkt sie verwenden — und ich baue sie nur einmal.
Der Beweis: Worklino in 18 Tagen
Worklino habe ich am 7. April initial committet. Am 14. April lief das MVP produktiv. 18 Tage. Inklusive: Auth mit JWT und Refresh-Token, Organisations-System mit Invitations, Profile, Settings, Members-Management, Projekte, Kunden, Angebote, Rechnungen, Voice-Notes, Timeline, mobile Navigation, PWA-Manifest.
Das ist nicht magisch. Das geht, weil 80 Prozent des Codes aus dem geteilten CoreFramework und den bestehenden Modulen kam. Ich habe nur das spezifisch Worklino-spezifische gebaut.
Ein anderes Beispiel: External Login mit Microsoft und Google. Einmal im CoreFramework gebaut — funktioniert seither in allen acht Host-Apps. Bei separaten Repos wäre das fünf bis sechs Mal die gleiche Arbeit gewesen.
Modular Monolith ist nicht Kompromiss, sondern Konsequenz
Für ein 50-Personen-Startup mit drei Engineering-Teams sind Microservices die richtige Wahl. Für mich nicht. Für einen Solo-Builder mit Produktportfolio gibt es genau eine vernünftige Architektur: einen Modularen Monolith mit geteiltem Kern und sauber abgegrenzten Modulen.
Das ist keine Notlösung. Das ist die einzige Wahl, die Sinn ergibt.
In den nächsten Wochen schreibe ich mehr darüber: wie die Module konkret aussehen, wo der Schnitt zwischen CoreFramework und Produkt verläuft, was schiefgeht und wie ich es repariere. Wenn dich das interessiert, bleib dran.
