Build vs Buy bei internen Tools: Wann Gründer selbst bauen sollten

Bauen Sie ein internes Tool, wenn es Ihre Kerndaten oder Ihren Kernprozess berührt, wenn SaaS-Preise pro Sitzplatz schneller skalieren, als es Ihre Mitarbeiterzahl rechtfertigt, oder wenn die Standardlösung Ihr Team zwingt, jeden Tag Workarounds zu bauen. Kaufen Sie, wenn das Tool ein Standardprodukt ist, wenn Ihr Bedarf typisch ist und wenn Sie die Verfügbarkeit und Sicherheit des Anbieters lieber mieten als besitzen möchten. KI-gestützte Entwicklung hat die Grenze in Richtung Bauen verschoben, aber sie hat die Grenze bei der Wartung nicht verschoben – und genau dort verrechnen sich die meisten Gründer.

Warum die Frage wieder auf dem Tisch liegt

Ein Jahrzehnt lang galt für Gründer der einfache Standardrat: Bauen Sie niemals, was Sie kaufen können. Entwicklungszeit war knapp, SaaS war günstig, und jede Stunde, die in ein internes Tool floss, war eine Stunde weniger für das eigentliche Produkt.

Dieser Rat stammt aus einer Zeit, in der ein „kleines" internes Tool einem Team ein Quartal kostete. Das ist nicht mehr so. Entwickler bauen heute routinemäßig eine eng umrissene Version eines kommerziellen Produkts – einen Browser-Screenrecorder, ein Foto-Suchtool, ein schlankes CRM – an einem Wochenende nach, wobei ein LLM den Großteil der Tipparbeit übernimmt. Die Kosten der ersten Version sind eingebrochen.

Aber die erste Version war nie der teure Teil. Das Besitzen der Sache ist es. Unsere eigene Outreach-Engine, weiter unten beschrieben, hat deutlich weniger Zeit gekostet, bis sie lief, als es gekostet hat, sie lauffähig zu halten: Scraper brechen, Modellversionen ändern sich, und ein Entwickler verbringt immer noch jeden Monat einen Teil seiner Zeit damit. Die erste Version war billig. Das zweite Jahr ist der eigentliche Preis. Die Frage hat sich also verändert – von „können wir uns leisten, das zu bauen" zu „können wir es uns leisten, das am Leben zu halten" –, und das braucht ein anderes Framework.

Die vier Fragen, die darüber entscheiden

1. Sitzt das Tool auf Ihren Kerndaten?

Wenn das Tool die Daten liest oder schreibt, die Ihr Geschäft wertvoll machen – Kundendatensätze, Nutzungsdaten, klinische Notizen, Preislogik –, bedeutet Kaufen, Ihr wichtigstes Asset dem Datenmodell und der Exportpolitik eines Anbieters zu überlassen. Sie werden Monate damit verbringen, gegen dessen Schema und API-Limits anzukämpfen. Tools auf Kerndaten neigen stark zum Bauen.

Wenn das Tool Daten enthält, die Sie nicht vermissen würden – Meeting-Aufnahmen, Design-Mockups, Standup-Notizen –, kaufen Sie es und machen weiter.

2. Wie skaliert der SaaS-Preis?

Pro-Sitzplatz-Preise sind die Falle. Bei fünf Personen wirkt das trivial, und bei vierzig wird es zum Posten, nach dem der Finanzleiter fragt. Rechnen Sie die Dreijahreskosten durch, bevor Sie unterschreiben.

Ein veranschaulichendes Beispiel: Ein Tool zu 30 $ pro Sitzplatz und Monat für 40 Personen kostet 14.400 $ im Jahr, oder 43.200 $ über drei Jahre. Das noch vor dem unvermeidlichen Tier-Upgrade, wenn Sie SSO oder ein Audit-Log brauchen. Ein fokussiertes internes Tool, das in zwei bis drei Wochen gebaut und ein bis zwei Tage im Monat gewartet wird, liegt über denselben Zeitraum meist deutlich darunter.

Nutzungsbasierte Preise sind freundlicher. Wenn Sie nur für das zahlen, was Sie nutzen, und die Nutzung dem Umsatz folgt, ist Kaufen auch in größerem Maßstab oft in Ordnung.

3. Wer repariert es, wenn es kaputt geht?

Das ist die Frage, die Gründer gerne überspringen. Ein internes Tool hat Abhängigkeiten, die verrotten: eine Drittanbieter-API, die ihren Auth-Flow ändert, eine Datenbank, die eine Migration braucht, und ein Sicherheitspatch, der an einem Freitag ansteht. Wenn niemand die Verantwortung trägt, wird es still zu der Art von Altlast, die wir in technischer Schuld managen beschreiben: funktionierend, ungeliebt und beängstigend anzufassen.

Regel: Ein internes Tool ohne benannten Verantwortlichen ist eine Verbindlichkeit, kein Asset. Wenn Sie nicht sagen können, wer es im nächsten Jahr pflegen wird, kaufen Sie.

4. Werden Sie es ständig weiterentwickeln?

Wenn sich Ihre Anforderungen an das Tool wöchentlich verschieben, weil Sie Ihren eigenen Prozess noch lernen, wird SaaS Ihnen auf jedem Schritt Widerstand leisten. Benutzerdefinierte Felder, Zapier-Klebstoff und Workaround-Tabellen stapeln sich. Bauen gewinnt, wenn das Tool ein bewegliches Ziel ist.

Wenn der Prozess stabil und standardisiert ist – Rechnungsstellung, Spesenabrechnungen, Terminbuchung –, hat der Anbieter das bereits besser gelöst, als Sie es tun werden.

Unser eigenes Beispiel: die Outreach-Engine

Wir betreiben unser eigenes Outbound-Geschäft in der Agentur, und diese Entscheidung stand bei uns ganz konkret an. Die fertigen Personalisierungstools produzierten entweder generische E-Mails oder berechneten pro Enrichment-Credit in einer Weise, die mit dem von uns gewünschten Volumen schlecht skalierte.

Also haben wir es gebaut. Eine selbst gehostete Firecrawl-Instanz scrapt die Website jedes Prospects, ein lokales LLM liest das Ergebnis, und die Engine schreibt pro Unternehmen eine maßgeschneiderte E-Mail. Sie läuft auf Hardware, die wir bereits hatten, sodass die Grenzkosten pro Prospect nahe null liegen.

Der Teil, der für Build versus Buy entscheidend war, war das, was nach der ersten Version passierte. Unsere ursprüngliche Pipeline verkettete mehrere Schritte: Fakten über das Unternehmen extrahieren, den Winkel planen, dann entwerfen. Als wir das zu einem einzigen Call zusammenfassten, der gleichzeitig extrahiert und entwirft, schnitt das sowohl bei Kosten als auch bei Qualität besser ab. Das konnten wir nur herausfinden, weil wir das Tool besaßen und die Prompt-Architektur an einem Nachmittag ändern konnten. Bei einem SaaS-Produkt steht Ihnen dieses Experiment nicht zur Verfügung. Das allgemeine Muster behandeln wir in Single Call vs. Agent-Ketten, den konkreten Fall in KI-Cold-Email-Agent: Build vs. Buy.

Die ehrlichen Kosten dieser Entscheidung sind, dass ein Entwickler jeden Monat einen Teil seiner Zeit damit verbringt, das System gesund zu halten, weil Scraper brechen und sich Modellversionen ändern. Wir halten das für lohnend. Sie sollten entscheiden, ob Ihr Äquivalent es ebenfalls ist.

Wie ein gutes „Build" aussieht

Wenn die vier Fragen auf Bauen hindeuten, bleiben Sie diszipliniert:

• Auf einen Workflow begrenzen. Nicht „ein internes CRM", sondern „die Ansicht, die der Sales-Lead jeden Montagmorgen braucht". Sie können später erweitern.
• Einen langweiligen Stack verwenden. Für uns sind das Next.js, PostgreSQL oder Supabase und TypeScript. Manchmal ist es nur ein Script und ein Cron-Job. Das Ziel ist, dass jeder Entwickler im Team es reparieren kann.
• Die erste Version zeitlich begrenzen. Ein bis drei Wochen. Wenn das nicht passt, ist das Tool größer als gedacht.
• Einen Verantwortlichen benennen und dessen Zeit einplanen. Behandeln Sie es als kleines Produkt mit Backlog, nicht als Nebenprojekt.
• Instrumentieren. Ein Tool, von dem niemand weiß, dass es kaputt ist, ist schlimmer als gar kein Tool. Läufe loggen, bei Fehlern alarmieren.

Wann Kaufen klar richtig ist

Bei manchen Kategorien gibt es keinen Zweifel:

• Authentifizierung, Zahlungsabwicklung, transaktionale E-Mails. Die Sicherheit und Zustellbarkeit des Anbieters sind das Produkt. Besitzen Sie diese nicht selbst.
• Alles mit Compliance-Bezug. Wenn das Tool im Geltungsbereich von SOC 2, HIPAA oder einer Data-Residency-Prüfung liegt, wollen Sie die Bestätigung eines Anbieters, nicht Ihre eigene.
• Standard-Kollaboration. Videoanrufe, Dokumente, Chat. Ihre Version wird schlechter sein, und niemand wird es Ihnen danken.
• Alles, was Sie diese Woche brauchen und das nicht zum Kern gehört. Kaufen Sie es, setzen Sie eine Erinnerung für das Verlängerungsdatum und wenden Sie dann dieses Framework erneut an.

Eine Regel, die Sie in einem Meeting anwenden können

Bewerten Sie die vier Fragen. Wenn zwei oder mehr für Bauen sprechen, bauen Sie eine zeitlich begrenzte erste Version für einen Workflow mit einem benannten Verantwortlichen. Wenn weniger als zwei dafür sprechen, kaufen Sie und prüfen Sie es bei der nächsten Verlängerung erneut.

Wenden Sie das auf unsere Outreach-Engine an, und Sie sehen die Bewertung in der Praxis. Kerndaten: teilweise, da Prospect-Recherche in unsere Pipeline einfließt, wir aber den Verlust überleben würden. Preisgestaltung: Das Pro-Enrichment-Credit-Modell skalierte schlecht mit dem gewünschten Volumen, also Bauen. Verantwortlicher: ein Entwickler, benannt, mit eingeplanter Zeit jeden Monat, also ist Bauen vertretbar. Weiterentwicklung: Wir haben die Prompt-Architektur von einer mehrstufigen Kette zu einem einzelnen Call umgeschrieben, sobald wir Daten hatten, also Bauen. Drei von vier sprachen für Bauen, und die Entscheidung hat sich gehalten.

Schreiben Sie die Entscheidung und das Datum auf, denn die richtige Antwort ändert sich, während das Unternehmen wächst, und das Ehrliche ist, sie erneut zu prüfen, statt sie zu verteidigen.

Wo eine Agentur ins Bild passt

Den meisten Gründern fehlt nicht die Urteilskraft für diese Entscheidung. Ihnen fehlt ein Entwickler mit zwei freien Wochen. Das ist die Lücke, die wir schließen: ein eng umrissenes internes Tool, gebaut auf einem Stack, den Ihr Team bereits kennt, übergeben mit einer Bedienungsanleitung statt mit einer Abhängigkeit. Wenn Sie vor einer SaaS-Verlängerung stehen und sich fragen, ob Sie stattdessen bauen sollten, sprechen Sie mit uns.