Revenue-Intelligence selbst bauen — was es wirklich kostet
Mit ChatGPT, n8n und ein paar APIs steht ein erster Prototyp an einem Wochenende. Die eigentlichen Kosten entstehen danach — und die stehen in keinem Wochenend-Plan.
von Anita Suk · aktualisiert am
- Ein funktionierender Prototyp ist in einem Wochenende machbar — der Build selbst ist nicht das Teure.
- Die Kosten kommen danach: Wartung, Datenqualität, Drift, fehlendes Memory, und der Bus-Faktor, wenn die eine Person geht.
- Selbst bauen ist nicht die Lizenz, die man spart, sondern die Dauerlast, die man übernimmt.
- Sinnvoll als Lern- oder echtes Differenzierungsprojekt — sonst bindet es Tech-Zeit, die im Mittelstand meist knapper ist als das Tool-Budget.
Was man an einem Wochenende baut (und was nicht)
Mit ChatGPT oder Claude, n8n und ein paar APIs (CRM, Enrichment) steht schnell ein Flow: Lead rein, angereichert, grob bewertet, ins CRM geschrieben. Das ist ehrlich beeindruckend — und genau die Falle. Der Prototyp beweist, dass es geht, nicht, dass es trägt. Was ihm fehlt: ein robustes Scoring-Modell, versioniertes Memory, Fehlerbehandlung, und jemand, der ihn in sechs Monaten noch versteht.
Die versteckten Kosten: Wartung, Drift, Memory
APIs ändern sich, Prompts driften, Datenqualität schwankt, Edge-Cases tauchen auf. Ohne lebendiges Memory veralten die ICP-Annahmen, und der Output wird langsam falsch, ohne dass es jemand merkt. Wartung ist hier kein Projekt mit Enddatum, sondern ein Dauerzustand — Stunden pro Woche, die im Wochenend-Build niemand eingeplant hat.
Der Bus-Faktor
Der Eigenbau lebt im Kopf der einen Person, die ihn gebaut hat. Wechselt sie das Team, geht in Elternzeit oder verlässt die Firma, ist das System eine Blackbox. Ein Tool, das nur eine Person warten kann, ist ein Risiko, kein Asset — und im kleinen Team ist diese eine Person selten ersetzbar.
Wann Selbstbauen wirklich Sinn ergibt
Ehrlich: wenn der Bau selbst der Wert ist. Ein Lernprojekt, das Tech-Kompetenz im Haus aufbaut. Oder ein Prozess, der so einzigartig ist, dass er zum echten Differenzierungs-Asset wird und kein Standard-Tool ihn abbildet. Wer eine Tech-Ressource hat, die das dauerhaft tragen kann und will, soll bauen — das ist eine legitime, manchmal die richtige Wahl.
Bauen vs. kaufen: die ehrliche Rechnung
Die Frage ist nicht „was kostet der Build", sondern „was kostet es, das System zwei Jahre lang korrekt, aktuell und wartbar zu halten". Rechnet man Wartungsstunden, Drift-Korrektur und das Bus-Faktor-Risiko ein, kippt die Rechnung für die meisten Teams ohne dedizierte Tech-/GTM-Ressource Richtung kaufen.
…und wo GrowthKit hier sitzt
GrowthKit ist im Kern dieselbe Architektur — ICP-Scoring, Enrichment, Alignment, Memory, CRM-Writeback — aber gewartet, versioniert und lernend, ab 149 €/Monat. Der Unterschied ist nicht „könnt ihr das nicht selbst", sondern „wollt ihr es zwei Jahre lang selbst am Leben halten". Wer den Bau als Lern- oder USP-Projekt will, soll bauen; wer das Ergebnis ohne Dauerlast will, nimmt die Plattform.
→ Im Demo-Chat ausprobieren.
Glossar
- Drift
- Das schleichende Veralten von KI-Output, wenn Prompts, APIs oder hinterlegter Kontext nicht mitgepflegt werden.
- Bus-Faktor
- Das Risiko, dass nur eine Person ein System versteht und warten kann.
- Lebendiges Memory
- Strukturierter, versionierter, fortlaufend aktualisierter Kontext — was einem Eigenbau-Prototyp typischerweise fehlt (Context Leakage).
- Build vs. Buy
- Die Grundsatzentscheidung, eine Fähigkeit selbst zu entwickeln oder einzukaufen.
Häufige Fragen
Revenue-Intelligence ohne Dauerlast.
Im Demo-Chat ausprobieren, wie ICP-Scoring, Alignment und lebendiges Memory als fertiges Produkt zusammenspielen — ab 149 €/Monat, ohne Bus-Faktor.