Wie wir unser eigenes Produkt gelöscht haben – und warum das unsere beste Entscheidung war

Ein Auszug aus dem Vortrag unseres Technical Directors Alexander Isaenco auf der ML Conference in München.

Auf Tech-Konferenzen hört man meistens Erfolgsgeschichten: große Vision, harter Weg, explodierende Metriken, glückliche Kunden. Alexander Isaenco hat auf der MLCon in München eine andere Geschichte erzählt – die von einem teuren Realitätscheck. Und davon, warum das Löschen von Millionen Zeilen Code manchmal das beste Produkt-Release ist.

Hier die wichtigsten Learnings aus über zwei Jahren Produktentwicklung – ehrlich, ohne Hochglanz.

Der Anfang: Ein Prototyp, der zu gut funktionierte

Die Idee war solide. In jedem AI-Projekt wiederholen sich dieselben Aufgaben: Datenaufbereitung, Pipelines, Deployment, Logging. Warum also nicht eine Plattform bauen, die genau diese Routine abnimmt?

Die ersten internen Tools funktionierten hervorragend. Und genau da schnappte die Falle zu: Weil es funktionierte, wurden wir gierig. Aus ein paar Utilities sollte ein universeller Baukasten werden – modular, für jeden nutzbar.

Insight #1: Ein Prototyp beweist die Idee, nicht das Produkt.

„Es läuft in der Demo" und „es läuft beim Kunden" sind zwei völlig verschiedene Projekte. Das zweite muss man bewusst planen – nicht aus Versehen bauen.

Das Problem war nicht zu wenig Erfahrung. Sondern zu viel.

Klingt paradox, ist aber der Kern der Geschichte: Wir haben seit über 25 Jahren komplexe, ausfallsichere Enterprise-Architekturen für Kunden gebaut. Genau diese Denkweise haben wir auf ein junges Produkt übertragen – schwere Architektur, zu viele Senior-Entwickler, ständige Team-Rotation, weil die Ressourcen da waren.

Dazu kam die Service-Mentalität: Wer im Enterprise-Geschäft groß geworden ist, sagt zu jedem Kundenwunsch „ja" und findet einen Weg. Unsere Produkt-Roadmap sah entsprechend aus wie ein Service-Backlog:

• „Ein Kunde auf Projekt X braucht diesen Edge Case – rein damit."
• „Auf GitHub gibt's ein spannendes Konzept – bauen wir ein."
• „Das brauchen wir vielleicht später – ab in die Kern-Architektur."

Jede einzelne Idee war für sich genommen vernünftig. Genau das macht es so gefährlich.

Insight #2: Nicht dumme Ideen killen Produkte – dumme Ideen lehnt jeder ab.

Es sind die vernünftigen, logischen Ideen, die ohne strengen Produktrahmen die Architektur ins Chaos mutieren lassen. Ein Produkt braucht einen Owner, der die „Nein"-Liste verteidigt. Sie ist wertvoller als jede Feature-Liste.

Dann kam der LLM-Hype

ChatGPT war plötzlich überall, und FOMO übernahm das Steuer. Wir stoppten halbfertige Features und pressten RAG-Funktionen in eine Plattform, die längst an Frankensteins Monster erinnerte. Statt fokussierter Nische: eine schwerfällige Alternative zu Hyperscalern, mit denen wir nie konkurrieren wollten – und konnten.

Insight #3: Bewegung ist nicht Fortschritt.

Features zu shippen fühlt sich wie Gewinnen an. Man kann sehr schnell in die falsche Richtung sprinten.

Der Realitätscheck: Dogfooding

Der Wendepunkt kam, als wir unsere Plattform konsequent für die eigenen internen Prozesse einsetzten. In der Demo sah die Drag-and-Drop-Oberfläche wunderschön aus. In der Produktion: ein Albtraum. Eine simple Prompt-Änderung erforderte Custom Scripts und ein komplettes Redeployment. Ein Senior Engineer brauchte drei Stunden, um ein Stück Metadaten zwischen zwei Nodes zu übergeben.

80 % der Zeit kämpften wir gegen unser eigenes Tool, 20 % lösten wir das eigentliche Problem. Die ehrlichste Erkenntnis: Wir, die Macher, hassten es, unser eigenes Produkt zu benutzen.

Insight #4: Dogfooding ist der ultimative Realitätscheck.

Wenn das eigene Team unglücklich Workarounds baut, werden es die Kunden auch sein. Und: Jede „temporäre" Lösung braucht ein Ablaufdatum – sonst wird der Workaround leise zur Architektur.

Der Reset: Löschen statt Flicken

Wir stellten eine banale Frage: Wer nutzt dieses System eigentlich wirklich? Die Antwort: unsere eigenen Entwickler. Und was hassen Entwickler mehr als alles andere? Aufgeblähte Low-Code-Oberflächen, die ihnen die Kontrolle wegnehmen. Wir hatten eine visuelle Plattform für Menschen gebaut, die lieber Code schreiben.

Also haben wir sie gelöscht – die Low-Code-Plattform, das massive UI, die Hyperscaler-Ambitionen. Übrig blieb ein fokussiertes Setup:

• Code-First Python-Framework: Engineers schreiben Code in ihrer IDE nach einem einheitlichen Standard – volle Flexibilität statt Drag-and-Drop.
• Minimalistische Ausführungsschicht: Ein schlankes UI nur für Monitoring, Logging und Deployment. Keine Logik im Interface.
• Isolierte Business Cases: Jede Kundenlösung ist eine eigene Einheit. Fällt ein Workflow aus, bleibt die Plattform stabil.

Insight #5: Sunk Costs sind eine psychologische Falle.

Wer einer Sackgasse Features hinzufügt, baut daraus keine Tür. Die wichtigste Produktentscheidung war nicht, was wir hinzufügen – sondern was wir löschen.

Was das für Ihre AI-Projekte bedeutet: AI Readiness

Aus dieser Erfahrung ist unser wichtigster Beratungsgrundsatz entstanden: Bevor wir für einen Kunden eine einzige Zeile Code schreiben, prüfen wir die AI Readiness:

• Sind die Daten sauber, zugänglich und rechtlich geklärt?
• Wo liegt der tatsächliche Business-Engpass?
• Gibt es messbare KPIs für den Erfolg?

Der Markt drängt Unternehmen dazu, LLMs auf alles anzuwenden. Wir tun das bewusst nicht. Manchmal löst ein SQL-Script das Problem besser als ein AI-Agent – und genau das sagen wir dann auch. Heute laufen unsere eigenen Prozesse auf diesem Fundament: Angebotserstellung mit Transkript-Analyse und ReAct-Agenten, HR-Automatisierung, Meeting Notes. Nicht weil AI trendy ist, sondern weil der Business Case vorher validiert wurde.

Fazit

Produktreife beginnt in dem Moment, in dem man aufhört, alte Entscheidungen zu verteidigen. Das größte Upgrade ist nicht mehr Features – es ist das Löschen des Rauschens.

Sie planen ein AI-Projekt – oder stecken mitten in einem, das sich anfühlt wie oben beschrieben? Wir bauen Custom Solutions, die in der Produktion funktionieren, nicht nur in der Demo. Und wenn AI nicht die richtige Antwort ist, sagen wir Ihnen das ehrlich. Sprechen Sie mit uns.