Field Note: Warum ich lieber ein kleines eigenes Tool baue als SaaS einzukaufen

Ich baue nicht alles selbst – aber ich kaufe auch nicht jeden Prozess ein

Wenn ein vorhandenes SaaS einen Prozess nur ungefähr abbildet, prüfe ich lieber, ob ein kleines eigenes Tool die bessere Lösung ist. Nicht, weil Eigenentwicklung grundsätzlich überlegen wäre. Sondern weil ich wissen möchte, welche Teile meines Arbeitsablaufs ich wirklich brauche – und welche ich nur mitbezahle oder umständlich umgehe.

Ein gutes SaaS kann viel Arbeit abnehmen: Betrieb, Updates, Funktionen, manchmal auch die Verantwortung für technische Details. Wenn der Prozess nah am Standard liegt und das Tool gut hineinpasst, ist das oft genau richtig. Ich möchte nicht aus Prinzip etwas selbst betreiben, das ein zuverlässiger Dienst einfacher erledigt.

Misstrauisch werde ich, wenn das Tool größer ist als das Problem. Wenn ich den Arbeitsablauf an die Oberfläche anpassen muss, statt umgekehrt. Wenn wichtige Daten nicht dorthin fließen können, wo sie gebraucht werden. Oder wenn die Kosten mit jeder zusätzlichen Nutzung stärker wachsen als der Nutzen.

Was ich zuerst prüfe: Ist das Problem wirklich fehlende Software – oder fehlt mir zuerst ein klares Verständnis des Prozesses?

Der erste Impuls ist nicht immer die richtige Entscheidung

Mein erster Impuls bei einem wiederkehrenden manuellen Schritt kann sein: Das sollte sich doch automatisieren lassen. Aber aus einem nervigen Schritt wird nicht automatisch ein sinnvoller Softwareprozess. Vielleicht ist der Ablauf noch nicht stabil. Vielleicht hängt eine Entscheidung an Wissen, das nirgends festgehalten ist. Oder vielleicht kommt der Schritt so selten vor, dass ein eigenes Tool mehr Pflege erzeugt, als es Arbeit spart.

Deshalb automatisiere ich nicht, bevor ich verstanden habe, was tatsächlich passiert. Ich schaue mir an, welche Informationen hineingehen, welche Entscheidungen getroffen werden und welches Ergebnis herauskommen soll. Dabei interessiert mich auch, wo ein Mensch prüfen oder freigeben muss. Erst wenn diese Übergänge klar sind, kann ich beurteilen, ob ein bestehendes Produkt reicht, eine Integration genügt oder eine eigene Lösung sinnvoll wird.

Das ist für mich der Unterschied zwischen „ein Tool bauen“ und „einen Prozess abbilden“. Im ersten Fall beginnt man schnell mit Funktionen. Im zweiten versucht man zunächst, die Arbeit und ihre Regeln zu verstehen. Diese Reihenfolge spart nicht immer Entwicklung. Sie verhindert aber, dass ich einen unklaren Ablauf in Software gieße und danach seine Unklarheiten pflegen muss.

Wann ich ein eigenes Tool ernsthaft erwäge

Es gibt ein paar Situationen, in denen ich genauer hinschaue. Datenhoheit ist wichtig, und ich möchte wissen, wo Daten liegen und wie ich auf sie zugreifen kann. Ein bestehendes Produkt ist für die Aufgabe deutlich zu groß. Der Prozess ist so spezifisch, dass ich ständig Sonderwege brauche. Eine nötige API fehlt. Oder die Kosten steigen mit der Nutzung so stark, dass die wirtschaftliche Logik auf Dauer nicht mehr passt.

Keiner dieser Punkte bedeutet für sich allein: selbst entwickeln. Eine fehlende API kann etwa ein vorübergehendes Hindernis sein, aber auch ein Hinweis darauf, dass das Produkt nicht zu einer zentralen Stelle im eigenen System werden sollte. Datenhoheit kann sich durch eine passende Konfiguration oder einen anderen Dienst lösen lassen. Und ein großes Produkt kann trotzdem sinnvoll sein, wenn seine Breite tatsächlich gebraucht wird.

Ich vergleiche deshalb nicht nur Lizenzkosten mit Entwicklungskosten. Ein eigenes Tool braucht ebenfalls Aufmerksamkeit: Es muss betrieben, verstanden und bei Bedarf verändert werden. Auch ein kleiner, selbst gehosteter Dienst ist nicht kostenlos, nur weil keine monatliche SaaS-Rechnung kommt. Die relevante Frage ist eher, welche laufende Arbeit ich übernehme – und ob ich dadurch mehr Kontrolle oder Passgenauigkeit gewinne, als ich an anderer Stelle an Aufwand dazubekomme.

Klein heißt: nur die Verantwortung übernehmen, die ich brauche

Bei eigenen Werkzeugen suche ich nicht nach der möglichst vollständigen Plattform. Ich suche nach dem kleinsten System, das eine klar umrissene Aufgabe zuverlässig erledigt. Das kann ein spezialisiertes Plugin sein, eine kleine Anwendung oder ein Backend, das nur die benötigte Logik enthält. Die Form ergibt sich aus dem Prozess; sie muss keinem Architekturtrend folgen.

Die Engine Room ist ein Beispiel dafür, wie ich diese Haltung in eigene Werkzeuge übersetze. Die Plugin-Suite besteht aus spezialisierten Engines für Aufgaben wie Inhalte, interne Links, Suche, SEO, Performance, Automatisierung und statische Releases. Mir ist dabei wichtig, Änderungen nicht einfach auszuführen und zu hoffen, dass alles gutgeht. Das Prinzip lautet Know → Change → Prove: erst den Zustand erfassen, dann eine Änderung nach Vorschau und Freigabe ausführen und anschließend ihre Wirkung belegen.

Das ist kein Argument dafür, jedes Unternehmen brauche eine eigene Plugin-Suite. Für mich zeigt es eher, wie ich ein Werkzeug begrenze: Es soll eine konkrete Aufgabe lösen und die Veränderung kontrollierbar machen. Gerade bei Automatisierungen finde ich die Frage wichtig, ob sich ein Schritt später nachvollziehen und gegebenenfalls zurücknehmen lässt.

Ein anderes Beispiel ist Ting. Dort antworten mehrere KI-Anbieter unabhängig, stimmen strukturiert ab und geben Ergebnisse nur bei Einstimmigkeit frei. Die Entscheidung für eine eigene Lösung hängt hier mit einem spezifischen Ablauf zusammen: Antworten, Bewertung und Freigabe sind als zusammengehöriger Prozess gedacht. Das ist etwas anderes, als einfach ein weiteres Chatfenster bereitzustellen.

Beim Backend von eisenross ist die Lösung bewusst klein und frameworkfrei: PHP und MySQL, auf einfachem Hosting. Es importiert Awin-Feeds und bildet die benötigte Produktlogik ab, darunter Klassifizierung und Ranking. Produkte werden erst nach Freigabe öffentlich. Der wichtige Punkt für mich ist nicht, dass ein Framework oder ein größeres System grundsätzlich falsch wäre. Sondern dass ich die technische Form an der konkreten Aufgabe ausrichte und nicht mehr Infrastruktur einführe, als dafür nötig ist.

Was ich heute anders mache

Früher kann ein fehlendes Feature leicht wie ein Auftrag zum Selberbauen wirken. Heute frage ich zuerst, ob dieses Feature wirklich zum Kern des Prozesses gehört. Vielleicht reicht eine andere Konfiguration. Vielleicht ist eine Integration die bessere Grenze zwischen zwei Systemen. Vielleicht muss ich den Ablauf vereinfachen, statt ihn noch genauer in Software abzubilden.

Ich baue auch nicht selbst, nur weil ich es kann. Ein eigenes Tool braucht einen klaren Zweck und einen überschaubaren Verantwortungsbereich. Wenn ein Standardprodukt den Prozess gut trägt, lasse ich es das tun. Wenn nur ein Teil nicht passt, suche ich zunächst nach einer kleinen Ergänzung statt nach einem vollständigen Ersatz. Und wenn die Anforderungen so speziell sind, dass ich ein System ohnehin dauerhaft verbiegen müsste, wird eine eigene Lösung plausibler.

Meine Faustregel: Ich kaufe ein SaaS, wenn es den Prozess sauber trägt. Ich baue ein eigenes Tool, wenn Kontrolle, Spezifität oder fehlende Schnittstellen wichtiger werden als die Bequemlichkeit des Einkaufs – und wenn ich bereit bin, das Werkzeug anschließend auch zu betreiben.

Weiterführend

• SaaS oder individuelle Software: Wann Eigenentwicklung wirtschaftlich wird
• n8n vs. eigene Entwicklung für Automatisierungen
• Engine Room