Produkte

Beratung hat ein strukturelles Problem: Man empfiehlt Entscheidungen, deren Folgen jemand anderes zwei Jahre später trägt. Wer nie selbst betreibt, was er vorschlägt, verliert mit der Zeit das Gefühl dafür, welche Empfehlungen im Alltag halten und welche nur auf Folien gut aussehen.

Eigene Produkte korrigieren das. Wir bezahlen unsere eigenen Cloud-Rechnungen, betreiben unsere eigenen Cluster, werden von unseren eigenen Alarmen geweckt und müssen unsere eigenen Datenschutzkonzepte gegenüber echten Nutzern vertreten. Eine Architektur, die wir für uns selbst nicht wählen würden, empfehlen wir auch nicht weiter.

Der zweite Grund ist Ehrlichkeit gegenüber Interessenten. Jede Beratung behauptet Erfahrung mit Kubernetes, Stripe-Integrationen oder App-Veröffentlichungen. Nachprüfbar wird das erst, wenn etwas Laufendes dahintersteht, das man aufrufen, herunterladen und kritisieren kann.

Deshalb steht bei jedem Produkt nicht nur, was es tut, sondern auch was daran schwierig war. Bei CICDX war es die Erkenntnis, dass die letzten zehn Prozent einer Pipeline-Migration nicht automatisierbar sind und ein Werkzeug sie deshalb markieren statt raten muss. Bei Lieferhand waren es die Auszahlungen und der Datenschutz rund um Ausweisprüfungen, nicht der Marktplatz selbst. Bei CryptoTarget war es die Rechnung für Livedaten, die aus einem Nebenprojekt beinahe ein Abonnement gemacht hätte.

Diese drei Lehren tauchen in unserer Kundenarbeit regelmäßig wieder auf — bei Migrationen, bei Zahlungsanbindungen und immer dann, wenn jemand die laufenden Kosten einer Architektur erst nach dem Bauen ausrechnet.

Alle drei laufen auf derselben Art von Infrastruktur, die wir auch Kunden empfehlen: Kubernetes dort, wo mehrere Dienste unabhängig skalieren müssen, verwaltete Datenbanken statt selbst betriebener, GitOps als einziger Weg in die Produktion. Nichts davon ist originell — originelle Infrastruktur ist meistens ein Warnsignal.

Interessanter ist, was wir dabei nicht gemacht haben. Lieferhand läuft nicht auf einer Multi-Cloud-Architektur, obwohl sich das gut vortragen ließe. CryptoTarget hat kein eigenes Backend für Nutzerkonten, weil es keine braucht. CICDX hatte anderthalb Jahre lang keine Weboberfläche, weil die Zielgruppe ohnehin im Terminal arbeitet. Weglassen ist die Entscheidung, die im Betrieb am meisten spart und in Angeboten am seltensten vorkommt.

Und alle drei kosten uns jeden Monat echtes Geld. Das ist der Grund, warum wir bei Architekturentscheidungen über laufende Kosten und Betriebsaufwand sprechen können und nicht nur über Bauzeit — die Rechnung kommt bei uns an derselben Stelle an wie bei Ihnen.

Ja, und die ehrlichere Antwort lautet: meistens sollten wir es nicht. Ein eigenes Produkt lohnt sich, wenn ein Prozess der Kern Ihres Geschäfts ist und kein Standardprodukt ihn trifft. In allen anderen Fällen ist gekaufte Software billiger — auch dann, wenn sie nur zu achtzig Prozent passt.

Wo die Grenze verläuft, klären wir im Erstgespräch. Wir haben genügend eigene Produkte gebaut, um zu wissen, dass der Aufwand nach dem ersten Release nicht endet, sondern dort erst anfängt.

Als grobe Orientierung: Die Entwicklung bis zur ersten nutzbaren Version ist erfahrungsgemäß etwa die Hälfte des Gesamtaufwands der ersten zwei Jahre. Die andere Hälfte sind Betrieb, Fehlerbehebung, Anpassungen an Schnittstellen, die sich ändern, und die Arbeit, die entsteht, wenn echte Nutzer Dinge tun, die im Konzept nicht vorgesehen waren. Wer nur die erste Hälfte einplant, hat kein Budget, sondern eine Anzahlung.

Der häufigste sinnvolle Mittelweg ist übrigens keiner von beiden Extremen: Standardsoftware als Basis, und die zwei oder drei Stellen, an denen Ihr Prozess wirklich abweicht, als eigene Erweiterung daneben. Das ist unspektakulär und in den meisten Fällen die Antwort mit dem besten Verhältnis.