Ein Klient rief mich 2021 an, echte Panik in seiner Stimme. Er hatte £140.000 über vierzehn Monate ausgegeben, um eine Custom-Invoicing-Plattform zu bauen. Sein Dev-Team hatte vielleicht 60% der Spezifikation geliefert. Und irgendwann im elften Monat hatte er herausgefunden, dass Invoice Ninja existierte, Open-Source war und 90% von dem, was er brauchte, direkt aus der Box bot. Kostenlos.
Wichtigste Erkenntnis: Kaufe SaaS, bis die Subscription Tax, Dateneigentum oder Workflow-Missmatch wirklich schmerzen; baue Custom, wenn das Tool zentral für den geschäftlichen Erfolg ist.
Das Gespräch verfolgt mich noch immer. Die ehrliche Antwort ist nämlich: Ich habe den gleichen Fehler selbst gemacht. Bei Seahawk gab es 2019 ein Projekt, wo wir acht Monate damit zugebracht haben, fünf verschiedene SaaS-Tools zusammenzuflicken – Airtable, Zapier, Typeform, HubSpot und ein Custom Webflow CMS – um einen Client-Workflow zu verwalten. Das hätte sich im Nachhinein mit einem £15.000 Custom-Build sauber und langfristig lösen lassen. Am Ende zahlten wir etwa £900 monatlich für alle Abos zusammen. Rechne das über drei Jahre durch.
Keines der Extreme ist automatisch richtig. Und wer dir eine saubere Regel verkauft, „immer bauen", „nie bauen", verkauft dir etwas. Also hier ist das echte Framework, das ich verwende, wenn sich ein Founder mit mir hinsetzt und die Frage stellt.
---
Erstens, Gib zu, was du eigentlich entscheidest
Das ist keine technische Entscheidung. Nicht wirklich. Es ist eine Geschäftsentscheidung, die sich in technischem Gewand präsentiert.
Wenn du fragst „sollte ich bauen oder kaufen?", fragst du eigentlich: wo lebt die Differenzierung in meinem Produkt? Wenn das Ding, das du in Betracht ziehst zu bauen, zentral für deine Wettbewerbsfähigkeit ist, der Grund, warum Kunden dich gegenüber dem nächsten Tab in ihrem Browser wählen werden, dann macht Bauen wahrscheinlich Sinn. Wenn es Infrastruktur, Administration oder Standard-Funktionalität ist, ist Kaufen fast sicher günstiger in echten Zahlen.
Ich stelle Foundern erst eine Frage: Werden deine User diese Sache je sehen? Wenn ja und es prägt ihre Experience auf sinnvolle Weise, könnte es sich zu bauen lohnen. Wenn es Back-Office, operativ oder intern ist, sollte die Hürde zum Bauen sehr hoch liegen.
---
Die echten Kosten des Bauens (Menschen unterschätzen das furchtbar)
Lass mich deutlich sein. Custom-Entwicklung kostet mehr als du denkst, dauert länger als dir gesagt wird, und erfordert laufende Wartung, für die niemand budgetiert.
Was Gründer tatsächlich vergessen einzukalkulieren
- Wartung und Hosting. Nicht einmalig. Du bist dafür am Haken, bis du die Sache vom Netz nimmst.
- Security-Patches. Ein SaaS-Vendor kümmert sich darum. Du baust, du besitzt es, inklusive der 2-Uhr-morgens-Alerts.
- Onboarding neuer Devs. Wenn dein Lead Engineer geht, muss die nächste Person deinen Codebase lernen. Das sind Wochen an billbaren Stunden.
- Feature Creep. Stakeholder sehen ein Custom-Tool und gehen davon aus, dass es alles kann. Der Scope expandiert. Kosten folgen.
Eine grobe Faustregel, die ich nutze: Nimm deine initialen Dev-Schätzungen, multipliziere mit 1,6 für realistische Lieferung, dann addiere 20% dieser Zahl jährlich für Wartung. Wenn diese Zahlen das Business Case immer noch rechtfertigen, großartig. Wenn nicht, hast du deine Antwort.
Ehrlich gesagt, die CHAOS Report der Standish Group zeigt seit Jahrzehnten, dass Softwareprojekte ihre Budgets mit alarmierender Rate überziehen. Die Zahl liegt bei etwa 45–50% der Projekte, die „problematisch" sind oder ganz scheitern. Das ist kein Grund, nie zu bauen, sondern ein Grund, mit offenen Augen reinzugehen.
---
Die wahren Kosten von SaaS (Auch unterschätzt, nur anders)
SaaS sieht billig aus, bis es das nicht mehr ist.
Der £49/Monat-Plan, der am Anfang des Jahres vernünftig schien, hat die lustige Angewohnheit, bis Jahr drei zu £490/Monat zu werden, sobald du auf einen höheren Tarif umgestiegen bist, mehr Plätze hinzugefügt hast und der Vendor eine „Preisumstrukturierung" gemacht hat (lies: Erhöhung). Ich habe das bei Kunden auf Salesforce, Intercom und Mixpanel gesehen. Es ist nicht böswillig. Es ist einfach, wie SaaS-Ökonomie funktioniert.
Die drei SaaS-Fallen, in die Gründer tappen
- Herstellerabhängigkeit. Deine Daten sind in ihrem Format, ihrem Schema, ihrem Export-Workflow. Zu gehen ist schmerzhaft und manchmal praktisch unmöglich ohne erhebliche Datenengineering-Arbeit.
- Franken-Stack-Komplexität. Fünf Tools, die sich via Zapier irgendwie integrieren, sind kein System. Das ist eine Haftung. Eine API-Abschaltung und schon fängt alles an auseinanderzufallen.
- Subscription Creep. Niemand prüft seinen Tool Stack jährlich. Sie sollten es. Ich habe letztes Jahr eine Prüfung für eine 12-köpfige Agentur durchgeführt und £3.200/Monat an SaaS gefunden, das sie entweder nicht mehr nutzten oder nur für ein Feature einsetzten.
Das gesagt, für Standard-Funktionen ist SaaS fast immer der richtige Ruf. Email-Versand? Postmark oder SendGrid. Zahlungen? Stripe, natürlich. Auth? Auth0 oder Clerk. Niemand sollte 2024 seinen eigenen Payment Processor bauen.
---
Ein Framework, das tatsächlich funktioniert
Richtig. So denke ich darüber. Vier Fragen, der Reihe nach.
Frage 1: Ist das ein Wettbewerbsvorteil?
Wenn ja, wenn das das Ding ist, das dein Produkt wirklich anders macht, ist Bauen es wert, ernst in Betracht gezogen zu werden. Wenn nein, stop hier. Kauf.
Frage 2: Gibt es eine ausreichend gute SaaS-Alternative?
Gut genug, nicht perfekt. Gründer bauen regelmäßig, weil „es da draußen nichts gibt, das genau das macht, was wir brauchen." Manchmal stimmt das. Oft bedeutet es, dass sie nicht gründlich genug gesucht haben oder dass sie verwechseln, „wir müssen das gut konfigurieren" mit „wir müssen etwas Neues bauen."
Ich verbringe mindestens zwei Stunden damit, den SaaS-Markt zu erforschen, bevor ich jemals einen Custom-Build empfehlen würde. Product Hunt und G2 sind hier echte Hilfen, nicht als Evangelium, sondern als Startinventar.
Frage 3: Was ist deine realistische Time-to-Value?
Ein SaaS-Tool kann heute live gehen. Ein Custom Build dauert mindestens Wochen, normalerweise Monate. Wenn Geschwindigkeit zählt, und bei Early-Stage-Unternehmen ist das fast immer der Fall, kaufen dir Zeit um zu lernen, was du wirklich brauchst, bevor du dich zum Bauen verpflichtest.
2022 arbeitete Seahawk mit einem Logistik-Startup zusammen, das ein Custom Route-Optimierungs-Dashboard wollte. Wir überzeugten sie, zuerst eine White-Label-API-Schicht zu nutzen (sie begannen mit Route4Me). Sechs Monate später wussten sie genau, welche drei Features ihre Kunden tatsächlich brauchten. Der Custom Build, den sie schließlich beauftragten, hatte den halben Umfang und war doppelt so gut, weil sie in der Produktion gelernt hatten, nicht in einem Spezifikationsdokument.
Frage 4: Was passiert, wenn das ausfällt?
Weil es kaputtgehen wird. Die Frage ist, wer es repariert und wie schnell. Bei SaaS reicht man ein Support-Ticket ein und beschwert sich auf Twitter. Bei Custom Software rufst du dein Dev-Team an. Wenn du kein Dev-Team unter Vertrag hast, bist du in Schwierigkeiten. Das ist keine Theorie, ich habe Gründer gesehen, die Wochen lang mit kaputtem Custom Software feststeckten, weil ihr Freelance-Entwickler in den Urlaub fuhr.
---
Wann das Custom-Bauen klar die richtige Entscheidung ist
Es gibt Situationen, in denen Custom offensichtlich korrekt ist. Lass mich sie deutlich benennen.
- Deine Kern-IP ist die Software selbst. Wenn du ein SaaS-Produkt verkaufst, kannst du das, was du verkaufst, nicht outsourcen.
- Regulatorische Anforderungen bedeuten, dass Standard-Lösungen nicht ausreichen. Bestimmte Fintech-, Healthcare- und Legal-Anwendungen haben Compliance-Anforderungen, die die meisten SaaS-Tools nicht erfüllen.
- Du hast bereits mit einem SaaS-Tool validiert und weißt genau, was du brauchst. Das ist die beste mögliche Position, bevor du einen Custom Build in Auftrag gibst.
- Die SaaS-Preisgestaltung im großen Maßstab ist wirklich teurer als Eigenentwicklung. Rechne es bei deiner projizierten Year-3-Nutzung durch. Manchmal gewinnt Custom rein wirtschaftlich.
---
Wann der Kauf eindeutig die richtige Entscheidung ist
Ebenso gibt es Situationen, in denen Kaufen offensichtlich ist:
- Du bist pre-revenue oder pre-product-market fit. Punkt.
- Die Funktion ist Commodity-Infrastruktur: Email, Payments, Auth, Storage, Analytics.
- Du brauchst es noch dieses Quartal, nicht erst dieses Jahr.
- Dein Team hat keine internen Entwicklungskapazitäten und du kannst es dir nicht leisten, ordnungsgemäß zu rekrutieren.
Ich würde auch sagen: Wenn du als Gründer baust, um eine schwierigere geschäftliche Entscheidung zu vermeiden, lohnt sich das zu hinterfragen. Custom-Builds können eine sehr teure Form von Prokrastination sein.
---
Der Hybrid-Ansatz (oft der intelligenteste Weg)
Hier ist die Sache, über die niemand ausreichend spricht: Build und Buy schließen sich nicht gegenseitig aus.
Der pragmatischste Ansatz, den ich wiederholt funktionieren sah, ist dieser: Kaufe die Commodity-Teile aggressiv und baue die dünne Schicht differenzierter Logik darauf. Dein CRM ist HubSpot. Dein Support Desk ist Intercom. Aber die maßgeschneiderte Workflow-Engine, die sie verbindet und deinen spezifischen Prozess automatisiert? Das sind zwei Wochen Custom Dev, nicht sechs Monate.
Bei Seahawk haben wir Hunderte von Websites auf WordPress, einer gekauften Plattform, mit Custom Plugins gebaut, die genuinely novel sind. Die Plattform deckt die 80%. Wir bauen die 20%, die zählen. Es ist langweilige Beratung. Es ist auch die Beratung, die am häufigsten funktioniert hat.
---
FAQ
Woher weiß ich, ob mein Use-Case wirklich einzigartig genug ist, um einen Custom Build zu rechtfertigen?
Ehrliche Antwort: die meisten sind es nicht. Beginne damit, einen ernsthaften Nachmittag zu verbringen – ich meine vier oder fünf Stunden, nicht zwanzig Minuten – und kartiere alle SaaS-Produkte in deiner Kategorie. Wenn du das getan hast und nichts deckt deine Kernvorgabe, frag dich selbst, ob diese Vorgabe tatsächlich jetzt notwendig ist oder ob es ein Nice-to-Have ist, das du zu einem Blocker erhoben hast. Wenn es wirklich notwendig und wirklich unterversorgt ist, das ist ein Signal, das es wert ist, ernst genommen zu werden.
Was ist das Minimum-Team, das Sie benötigen, um Custom Software verantwortungsvoll zu betreiben?
Mindestens: ein Entwickler, der die Codebasis tiefgreifend versteht, und entweder ein zweiter Entwickler oder eine unter Vertrag stehende Agentur, die abdecken kann, wenn dieser nicht verfügbar ist. Custom Software mit einem einzelnen Freelancer und ohne Backup zu besitzen ist eine fragile Position. Ich habe gesehen, wie es echten operativen Schaden verursachte, wenn diese Person nicht verfügbar wird – Urlaub, Krankheit, ein besseres Jobangebot.
Sollte ich intern entwickeln oder eine Agentur für Custom Development beauftragen?
Das hängt fast vollständig davon ab, ob Software dein Kerngeschäft ist. Wenn du ein Softwareunternehmen bist, möchtest du fast sicher irgendwann intern entwickeln, auch wenn du eine Agentur zum Start nutzt. Wenn Software ein Werkzeug ist, das dein Geschäft unterstützt, anstatt das Geschäft selbst zu sein, ist eine Agenturbeziehung mit einem ordentlichen SLA meist kostengünstiger als die Vollzeiteinstellung von Ingenieuren.
Ist Open-Source ein Mittelweg zwischen Eigenentwicklung und Zukauf?
Ja, und es wird untergenutzt. Tools wie Metabase für Analytics, Directus für Headless CMS oder ERPNext für Operations geben dir die Flexibilität von Custom Software mit deutlich niedrigeren anfänglichen Build-Kosten. Der Haken: Du besitzt trotzdem noch Infrastruktur und du brauchst trotzdem jemanden Technischen zu ihrer Verwaltung. Es ist nicht kostenlos, es ist einfach günstiger zum Starten.
---
Ein abschließender Gedanke
Die Frage zwischen Eigenentwicklung und Zukauf hat keine universelle Antwort. Sie hat Ihre Antwort, spezifisch für Ihr Stadium, Ihr Team, Ihre Wettbewerbsposition und das, was Sie bisher wirklich validiert haben.
Wogegen ich mich aussprechen würde, ist die Romantik ums Bauen. Custom Software ist nicht von Natur aus ernstafter, skalierbarer oder beeindruckender als ein gut konfigurierter SaaS-Stack. Der Invoicing-Gründer, den ich am Anfang erwähnte? Er baute schließlich etwas genuinely Custom, aber nur nachdem ihn achtzehn Monate mit Invoice Ninja genau gelehrt hatten, was seine Kunden tatsächlich brauchten. Der Build war besser für das Warten.
Beginne mit der langweiligen Option. Verdiene dir das Recht, etwas Neues zu bauen.
Weiterführende Lektüre: Building a Real-Time Auction Site with Next.js & Supabase, maßgeschneiderte Webentwicklung und Next.js.