Build vs. Buy für SaaS- und RevOps-Tools im KI-Zeitalter

Bauen Sie schmale Go-to-Market-Tools wie ein CPQ, einen Provisionsrechner oder einen Territory-Planer selbst, und kaufen Sie Ihre Systems of Record, also das CRM, das ERP und die Marketing-Automation-Plattform. KI-Coding-Tools haben schmale Tools günstig gemacht, aber ein System of Record bringt weiterhin Integrations-, Compliance- und Wartungsaufwand mit sich, der sich selten auszahlt.

Das ist unsere Position bei Revenue Wizards. Bei den Kernplattformen stehen wir klar auf der Seite des Kaufens. Bei den schmalen, regelbasierten Tools drumherum ist Selbstbauen für jedes Quartal mehr Teams das bessere Geschäft geworden.

Warum sich die Build-vs.-Buy-Debatte verändert hat

Die größte Debatte in SaaS ist derzeit, ob man Tools kauft oder selbst baut. Befürworter des Selbstbauens verweisen auf große Kosteneinsparungen. Gegner sagen, es sei riskant und man werde nicht in der Lage sein, das Gebaute zu warten.

Seit ich in der Tech-Branche arbeite, überraschen mich die Margen mancher SaaS-Unternehmen. SaaS Capital berichtet, dass die Bruttomargen auf SaaS-Lizenzumsätze in seinem Portfolio und seiner jährlichen Umfrage in der Regel bei 80% bis 85% liegen (SaaS Capital). Viele Anbieter reinvestieren stark in Wachstum, die Gewinne sind also geringer, aber jeder zusätzliche Nutzer kostet den Anbieter sehr wenig. Ein rationaler Käufer muss sich fragen, warum er dafür bezahlt.

Er bezahlt für Wert, oder wahrgenommenen Wert. Ein CRM macht eine Vertriebsorganisation weit effizienter als eine Tabelle. Ein Marketing-Automation-Tool automatisiert die repetitive Arbeit. Ein CPQ hilft bei Angeboten. Teams argumentieren zu Recht, dass diese Tools Zeit für wertvollere Arbeit freisetzen, und deshalb zahlen sie den Aufpreis.

KI stellt dieses Paradigma infrage. Viele Menschen können heute ein gleichwertiges Tool bauen, oder eines, das genau zu ihrem Anwendungsfall passt, zu einem Bruchteil der Kosten. Wenn das stimmt, bröckelt das Wertargument für den SaaS-Aufpreis.

Unsere eigenen Daten zeigen, wie weit das schon geht. In unserer Umfrage RevOps in 2026 unter 123 RevOps-Praktikern gaben 61% an, eigene KI-Tools zu bauen. Die genannten Beispiele waren praxisnah, etwa Quote-to-Cash-Systeme, CPQ, Territory- und Kapazitätsplanung, Agenten zur Dublettenbereinigung, Sales-Coaches, die Calls vorbereiten und Deals bewerten, sowie Forecast-Tooling. Ich erwarte, dass dieser Anteil weiter steigt, je einfacher die Modellanbieter das Bauen machen.

Welche Go-to-Market-Tools sollten Sie selbst bauen?

Es gibt Dutzende Go-to-Market-Tools, die Sie bauen können, vom Partnerportal über einen Provisionsrechner bis zu einem CPQ-Tool innerhalb von Salesforce oder HubSpot (Beispiel unten).

Ausgewählte Tools selbst zu bauen, kann wiederkehrende Lizenzkosten senken, aber die Einsparung hängt von Ihren aktuellen Abonnements, Ihrer Nutzung und den Kosten für Bau und Wartung des Ersatzes ab. Nutzen Sie unseren Build-vs.-Buy-Rechner, um die Lizenzkosten in Ihrem eigenen Tool-Stack abzuschätzen, bevor Sie entscheiden.

Eine Build-vs.-Buy-Scorecard für RevOps-Tools

Beantworten Sie für jedes infrage kommende Tool sieben Fragen. Jede Antwort zeigt in eine Richtung.

Frage	Spricht für Bauen	Spricht für Kaufen
Ist es ein System of Record (CRM, ERP, Marketing Automation)?	Nein	Ja
Ist der Umfang schmal, mit klaren Inputs und Outputs?	Ja	Nein
Ist die Logik spezifisch für Ihre Art zu verkaufen (Preisregeln, Vergütungspläne, Territorien)?	Ja	Sie ist generisch
Erledigt ein Tool, für das Sie bereits zahlen, die Aufgabe?	Nein	Ja
Wird eine namentlich benannte Person es nach dem Launch verantworten und pflegen?	Ja	Nein
Wie entwickeln sich die Lizenzkosten über drei bis fünf Jahre?	Sie steigen mit jedem zusätzlichen Seat	Flach oder gering
Wie schlimm ist ein Ausfall (Umsatzrealisierung, Compliance, Kunden)?	Gering und umkehrbar	Hoch

Zwei Antworten sind K.-o.-Kriterien. Ist es ein System of Record, kaufen Sie es. Wird es nach dem Launch niemand verantworten, kaufen Sie es oder lassen Sie es. Wenn ansonsten fünf oder mehr Antworten für das Bauen sprechen, investieren Sie eine Woche in einen Prototyp und vergleichen ihn mit dem Angebot des Anbieters auf Basis der Gesamtkosten, nicht des Lizenzpreises.

Unsere Five-Dots-RevOps-Wissensdatenbank betrachtet die Kostenseite genauso. Vergleichen Sie die Total Cost of Ownership über mehrere Jahre, einschließlich Lizenzen, interner Administrations- und Engineering-Zeit, externer Unterstützung und der Produktivitätskosten der Umstellung, nicht nur die Lizenzposition. Sie warnt auch vor einem klassischen Fehler, nämlich sich für eine Eigenentwicklung zu entscheiden, weil gerade Engineers verfügbar sind. Verfügbarkeit heute ist keine Verantwortung über Jahre.

Drei Build-vs.-Buy-Beispiele aus RevOps

Ein CPQ bauen Sie meist am besten innerhalb Ihres CRM. Angebotslogik ist schmal und ohnehin Ihre eigene. Ob Sie ein CPQ kaufen oder bauen, jede Preisregel, Freigabe und Schwelle definieren Sie selbst. Lizenzen pro Seat wachsen mit jedem neuen Angebotsersteller, während ein Eigenbau im CRM, das Sie bereits besitzen, im Wesentlichen einmalige Kosten plus Wartung verursacht. Das Argument wird schwächer, wenn Ihr Angebotsteam klein oder Ihre Governance schwach ist. Die Zahlen behandeln wir in unserer Aufschlüsselung der Salesforce-CPQ-Preise.

Territory- und Kapazitätsplanung lohnt sich oft als Eigenbau. Viele Teams erledigen das in Tabellen, denen niemand traut. Die Logik hängt von Ihren Segmenten, Ihrem Kapazitätsmodell und Ihren Daten ab, weshalb sie unter den internen Tools auftaucht, die die Teilnehmer unserer Umfrage beschrieben haben. Eine kleine App auf Basis der CRM-Daten, mit klarer Verantwortung, schlägt oft sowohl die Tabelle als auch eine Planungssuite, die Sie nur einmal im Jahr nutzen würden.

Conversation Intelligence sollten Sie kaufen. Aufzeichnung, Transkription, CRM-Updates und Coaching sind ein gelöstes Problem mit hohen Investitionen der Anbieter, und die Daten liegen bereits im Tool. Unsere Five-Dots-Wissensdatenbank sagt deutlich, dass Sie kein vertikales Tool nachbauen sollten, für das Sie bereits zahlen. Bauen Sie stattdessen den Workflow, der auf dessen Output reagiert, etwa die Weiterleitung einer Wettbewerbererwähnung an den richtigen Kanal.

Welche Skills und welches Team brauchen Sie, um GTM-Tools zu bauen?

Sie brauchen die Kompetenzen im Haus. Tools wie Lovable, Claude Code und Codex von OpenAI helfen beim Bau solcher Tools, und selbst Fachanwender kommen damit weit, aber besser ist es, wenn erfahrene Operator das Bauen übernehmen.

Ich würde noch weiter gehen und in echte Engineering-Ressourcen innerhalb des Revenue-Operations-Teams investieren. Ich meine keinen Go-to-Market Engineer ohne Programmierkenntnisse, sondern einen echten Entwickler. Diese Leute sparen Ihnen viel und bauen eine verlässliche Tooling-Infrastruktur für Ihr kommerzielles Team. Wo sie in der Struktur angesiedelt sind, behandelt unser RevOps-Organigramm für SaaS.

Die Teamgröße spielt eine Rolle. Unter etwa 20 Vertriebsmitarbeitenden werden Sie kaum einen eigenen Engineer einstellen, und Ihre RevOps-Leute können fokussierte Tools selbst bauen und pflegen. Darüber beginnt sich ein Entwickler innerhalb von RevOps selbst zu tragen.

Wenn Sie funktionierende Tools wollen, ohne zuerst ein Team aufzubauen, bauen unsere Forward Deployed GTM Engineers sie in Ihrem CRM und Stack, dokumentieren sie und übergeben sie an Ihre Leute. Buchen Sie ein Gespräch, und wir sagen Ihnen, welche Ihrer Tools sich zu bauen lohnen.

Häufige Einwände gegen selbst gebaute SaaS-Tools

Gegner des Selbstbauens bringen vier Einwände vor. Hier unsere Sicht auf jeden davon.

Erstens die Sicherheit. Dieses Argument verliert schnell an Gewicht. Low-Code-, No-Code- und Cloud-Plattformen übernehmen heute einen Großteil der Sicherheitseinrichtung, und viele GTM-Tools brauchen dieses Maß an Abschottung ohnehin nicht. Sie können auf Ihrer eigenen Infrastruktur hosten, Single Sign-on für die relevanten Funktionen einbinden und, wo Kunden es verlangen, das Tool in den Umfang einer SOC-2-Prüfung aufnehmen, des Berichts der AICPA über die Kontrollen eines Dienstleisters in Bezug auf Sicherheit, Verfügbarkeit, Verarbeitungsintegrität, Vertraulichkeit oder Datenschutz (AICPA).

Zweitens Personalabgänge. Viele sorgen sich, wer das Tool betreut, wenn die Person, die es gebaut hat, geht. Das ist eine berechtigte Sorge, aber eine kleinere als früher. Aktuelle Modelle sind sehr gut darin, saubere Dokumentation zu erstellen, sodass neue Mitarbeitende ein Tool übernehmen können, und dieselbe Dokumentation hilft dem Modell, das Tool mit den richtigen Prompts zu warten und zu verbessern. Investieren Sie vor allem in ein Team, das diese Tools pflegen kann. Das ist langfristig Ihr Wettbewerbsvorteil.

Drittens die Komplexität. Manche Tools sind zu komplex, um sie selbst zu bauen. Daran ist etwas Wahres, aber fast alles lässt sich bauen. Große Unternehmen mit großen Engineering-Teams entwickeln seit Jahrzehnten ihre Kernsysteme selbst, und eine ganze Branche von Individualsoftware-Firmen ist entstanden, um sie zu bauen und zu warten. Dass man etwas bauen kann, heißt nicht, dass man es sollte, und das bringt uns zu dem, was Sie nicht bauen sollten.

Viertens die Governance. Das ist der Einwand, der sich in unserer Arbeit mit Kunden am häufigsten bewahrheitet. Sobald Teams anfangen zu bauen, drohen doppelte Tools, Eigenbauten auf schlechten Quelldaten, an den falschen Stellen geteilte Zugangsdaten und Automatisierungen, die sonst niemand versteht. Die Teams, die das gut machen, führen ein Repository, kontrollieren den Zugriff, teilen Kontext und bauen eine zentrale Workflow-Ebene, während sie Daten- und Automatisierungsdienste darunter weiterhin einkaufen. Ein schlanker Tool-Stack gilt für das, was Sie bauen, genauso wie für das, was Sie kaufen.

Was Sie (noch) nicht bauen sollten

Das ERP, das CRM und die Marketing-Automation-Plattform würde ich vorerst nicht bauen.

Diese drei sind Systems of Record. Sie sind stark mit anderen Plattformen integriert, und individuelle Prozesse machen sie schnell komplex. Salesforce, HubSpot, Xero, NetSuite und vergleichbare Anbieter haben viel investiert, um sie zu perfektionieren. Eine Eigenentwicklung kann für ein kleines Unternehmen funktionieren, für ein mittelgroßes SaaS-Unternehmen oder ein größeres Unternehmen ist sie aber ein enormer Kraftakt. Stecken Sie den Aufwand lieber in das CRM-Datenmodell und beginnen Sie mit Tools, die einfacher sind und mehr bringen.

Einfach heißt nicht immer günstig. Das CPQ ist teuer, lässt sich aber nachbauen. Also, an alle, die bauen, legen wir los.

Wenn Sie das lieber gemeinsam mit erfahrenen Buildern angehen, buchen Sie ein Gespräch über unsere Forward Deployed GTM Engineers.

FAQ zu Build vs. Buy bei SaaS-Tools

Was sollte RevOps bauen statt kaufen?

Bauen Sie schmale, regelbasierte Tools, die Ihre Art zu verkaufen abbilden, etwa ein CPQ in Ihrem CRM, einen Provisionsrechner, Territory- und Kapazitätsplanung oder Agenten für Dublettenbereinigung und Datenanreicherung. Kaufen Sie Systems of Record und jedes Tool, das Ihr Stack bereits abdeckt.

Ist es günstiger, eigene SaaS-Tools mit KI zu bauen?

Oft, aber nicht automatisch. Selbstbauen beseitigt Lizenzkosten pro Seat, dafür übernehmen Sie Entwicklungszeit, Hosting und Wartung. Vergleichen Sie die Gesamtkosten über drei bis fünf Jahre, einschließlich der Person, die das Tool verantworten wird.

Sollten wir unser eigenes CRM bauen?

Nein, für die meisten Unternehmen nicht. Ein CRM ist ein System of Record mit tiefen Integrationen, Berechtigungen, Reporting und Compliance-Anforderungen, und eine Eigenentwicklung endet meist als schwächere Version der Plattform, die Sie hätten kaufen können.

Wer sollte individuelle GTM-Tools bauen und pflegen?

Jemand im kommerziellen Team, der jeden Tag da ist, idealerweise ein Engineer innerhalb von RevOps. Externe Builder können die erste Version erstellen, aber eine benannte interne verantwortliche Person muss sie pflegen, wenn sich Preise, Produkte und Prozesse ändern.

Wie entscheiden Sie zwischen Build und Buy?

Nutzen Sie eine kurze Scorecard. Sie fragt, ob es ein System of Record ist, wie schmal der Umfang ist, wie spezifisch die Logik ist, ob ein vorhandenes Tool es bereits leistet, wer es verantwortet, wie die Lizenzkosten wachsen und was ein Ausfall kostet. Systems of Record und Tools ohne Verantwortlichen sind K.-o.-Kriterien für das Selbstbauen.