Ein Kunde rief mich 2021 an — echte Panik in seiner Stimme. Er hatte £140.000 über vierzehn Monate ausgegeben, um eine benutzerdefinierte Rechnungsplattform zu bauen. Sein Dev-Team hatte vielleicht 60% der Spezifikation ausgeliefert. Und irgendwann im elften Monat hatte er entdeckt, dass Invoice Ninja existierte, Open-Source war und 90% von dem tat, was er brauchte — direkt ab Werk. Kostenlos.Invoice Ninjaexisted, was open-source, and did 90% of what he needed out of the box. For free.
Dieser Anruf verfolgt mich ein bisschen. Denn die ehrliche Antwort ist: Ich habe auch den gegenteiligen Fehler gemacht. Seahawk hatte ein Projekt 2019, in dem wir acht Monate damit verbracht haben, fünf verschiedene SaaS-Tools zusammenzusetzen — Airtable, Zapier, Typeform, HubSpot und ein benutzerdefiniertes Webflow CMS — um einen Client-Workflow zu verwalten, der rückblickend von einem £15.000 Custom Build sauber und dauerhaft hätte gelöst werden können. Wir zahlten am Ende ungefähr £900/Monat in kombinierten Abos. Rechne das über drei Jahre.
Keines der beiden Extreme ist automatisch richtig. Und wer dir eine saubere Regel verkauft — „immer bauen", „niemals bauen" — verkauft etwas. Also hier ist der eigentliche Rahmen, den ich verwende, wenn ein Gründer sich 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äftliche Entscheidung in technischem Gewand.
Wenn du fragst „sollte ich bauen oder kaufen?", fragst du eigentlich: Wo sitzt die Differenzierung in meinem Produkt? Wenn das, das du bauen möchtest, zum Kern deines Wettbewerbsvorteils gehört — der Grund, warum Kunden dich der nächsten Registerkarte in ihrem Browser vorziehen — dann macht Bauen wahrscheinlich Sinn. Wenn es Infrastruktur, Administration oder Standard-Funktionalität ist, ist Kaufen fast sicher günstiger in echten Zahlen.reasoncustomers will choose you over the next tab in their browser — then building probably makes sense. If it's infrastructure, admin, or commodity functionality, buying is almost certainly cheaper in real terms.
Ich stelle Gründern zuerst eine Frage: Werden deine Nutzer diese Sache jemals sehen? Wenn die Antwort ja ist und sie prägt ihre Erfahrung auf sinnvolle Weise, könnte es sich lohnen, es zu bauen. Wenn es Back-Office, operativ oder intern ist, sollte die Hürde für Bauen sehr hoch liegen.Will your users ever see this thing?If the answer is yes and it shapes their experience in a meaningful way, it might be worth building. If it's back-office, operational, or internal, the bar for building should be very high.
---
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 haftest dafür auf ewig, es sei denn, du stellst die Sache ein.Not a one-off. You're on the hook forever unless you sunset the thing.
- Sicherheits-Patches. Ein SaaS-Anbieter kümmert sich darum für dich. Du baust es, du ownst es, inklusive der Alerts um 2 Uhr morgens.A SaaS vendor handles this for you. You build it, you own it, including the 2am alerts.
- Onboarding neuer Entwickler. Wenn dein Lead-Engineer geht, muss die nächste Person deine Codebase lernen. Das sind Wochen an abrechenbarer Zeit.If your lead engineer leaves, the next person needs to learn your codebase. That's weeks of billable time.
- Feature Creep. Stakeholder sehen ein Custom Tool und gehen davon aus, dass es alles kann. Der Umfang wächst. Die Kosten folgen.Stakeholders see a custom tool and assume it can do everything. Scope expands. Costs follow.
Eine grobe Regel, die ich nutze: Nimm deine anfängliche Dev-Schätzung, multipliziere sie mit 1,6 für realistische Lieferung, dann addiere 20% dieser Zahl jährlich für Wartung. Wenn diese Zahlen immer noch den Business Case rechtfertigen, super. Wenn nicht, hast du deine Antwort.
Ehrlich gesagt zeigt der CHAOS Report der Standish Group seit Jahrzehnten, dass Softwareprojekte ihre Budgets in alarmierendem Ausmaß überschreiten. Die Quote liegt bei etwa 45-50% der Projekte, die „kritisch" sind oder komplett scheitern. Das ist kein Grund, nie zu bauen — es ist ein Grund, mit offenen Augen hineinzugehen.Standish Group's CHAOS Reporthas been showing for decades that software projects overrun their budgets at an alarming rate. The number sits around 45-50% of projects being "challenged" or outright failing. That's not a reason to never build — it's a reason to go in clear-eyed.
---
Die wahren Kosten von SaaS (Auch unterschätzt, nur anders)
SaaS sieht günstig aus, bis es nicht mehr günstig ist.
Der £49/Monat-Plan, der am Anfang des Jahres vernünftig wirkte, hat die lustige Angewohnheit, bis zum dritten Jahr zu £490/Monat zu werden — sobald du in einem höheren Tier bist, hast du Plätze hinzugefügt, und der Anbieter hat eine „Preisumstrukturierung" durchgeführt (sprich: Erhöhung). Ich habe das bei Clients bei Salesforce, Intercom und Mixpanel beobachtet. Es ist nicht bösartig. So funktioniert SaaS-Ökonomie einfach.
Die drei SaaS-Fallen, in die Gründer tappen
- Vendor Lock-in. Deine Daten sind in deren Format, deren Schema, deren Export-Flow. Zu gehen ist schmerzhaft und manchmal faktisch unmöglich, ohne erhebliche Data-Engineering-Arbeit.Your data is in their format, their schema, their export flow. Leaving is painful and sometimes effectively impossible without significant data engineering work.
- Franken-Stack-Komplexität. Fünf Tools, die sich irgendwie über Zapier integrieren, sind kein System. Es ist eine Haftung. Eine API-Abschaltung und die Dinge fangen an auseinanderzufallen.Five tools that sort-of integrate via Zapier is not a system. It's a liability. One API deprecation and things start falling apart.
- Subscription Creep. Niemand prüft seinen Tool-Stack jährlich. Das sollten sie tun. Ich habe letztes Jahr ein Audit für eine 12-köpfige Agentur durchgeführt und bin auf £3.200/Monat SaaS gestoßen, die sie entweder nicht mehr nutzten oder nur für eine Funktion verwendeten.Nobody audits their tool stack annually. They should. I ran an audit for a 12-person agency last year and found £3,200/month in SaaS they'd either stopped using or were using for one feature each.
Das gesagt — bei standardisierten Funktionen ist SaaS fast immer die richtige Wahl. E-Mail-Versand? Postmark oder SendGrid. Zahlungen? Stripe, offensichtlich. Authentifizierung? Auth0 oder Clerk. Niemand sollte 2024 seinen eigenen Payment Processor bauen.Postmarkor SendGrid. Payments? Stripe, obviously. Auth? Auth0 or Clerk. Nobody should be building their own payment processor in 2024.
---
Ein Framework, das tatsächlich funktioniert
Richtig. So denke ich darüber. Vier Fragen, der Reihe nach.
Frage 1: Ist das ein Wettbewerbsvorteil?
Falls ja — wenn das das ist, das dein Produkt wirklich unterscheidet — ist Eigenentwicklung ernsthaft zu erwägen. Falls nein, stopp hier. Kauf es.
Frage 2: Gibt es eine ausreichend gute SaaS-Alternative?
Ausreichend gut, nicht perfekt. Gründer bauen routiniert, weil "es da draußen nichts gibt, das genau das tut, was wir brauchen." Manchmal stimmt das. Oft bedeutet es, dass sie nicht gründlich genug gesucht haben oder verwechseln "wir müssen das gut konfigurieren" mit "wir müssen etwas Neues bauen."
Ich verbringe mindestens zwei Stunden damit, den SaaS-Markt zu recherchieren, bevor ich je eine Eigenentwicklung empfehlen würde. Product Hunt und G2 sind hier echte Klassiker — nicht als Bibel, aber als Ausgangsinventar.Product Huntand G2 are genuinely useful here — not as gospel but as a starting inventory.
Frage 3: Wie realistisch ist deine Time-to-Value?
Ein SaaS-Tool kann heute live gehen. Ein Custom Build dauert mindestens Wochen, meist Monate. Wenn Geschwindigkeit zählt – und in frühen Phasen fast immer – kaufst du 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-Dashboard zur Routenoptimierung wollte. Wir überredeten sie, zuerst einen White-Label-API-Layer zu nutzen (sie nutzten Route4Me als Ausgangspunkt). Sechs Monate später wussten sie genau, welche drei Features ihre Kunden wirklich brauchten. Der Custom Build, den sie später in Auftrag gaben, hatte den halben Umfang – und war doppelt so gut – weil sie in der Produktion gelernt hatten, nicht in einem Spezifikationsdokument.Route4Meas a starting point). Six months later, they knew exactly which three features their customers actually cared about. The custom build they eventually commissioned was half the scope — and twice as good — because they'd learned in production rather than in a spec document.
Frage 4: Was passiert, wenn das ausfällt?
Denn es wird ausfallen. Die Frage ist, wer es repariert und wie schnell. Bei SaaS öffnest du ein Support-Ticket und beschwderst dich 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 erlebt, die Wochen lang mit defekter Custom-Software festgesteckt haben, weil ihr Freelance-Entwickler in den Urlaub gefahren ist.
---
Wann das Custom-Bauen klar die richtige Entscheidung ist
Es gibt Situationen, in denen Custom offensichtlich korrekt ist. Lass mich sie deutlich benennen.
- Deine Core IP ist die Software selbst. Wenn du ein SaaS-Produkt verkaufst, kannst du das, das du verkaufst, nicht auslagern.If you're selling a SaaS product, you can't outsource the thing you're selling.
- 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.Certain fintech, healthcare, and legal applications have compliance constraints that most SaaS tools aren't built to satisfy.
- Du hast bereits mit einem SaaS-Tool validiert und weißt genau, was du brauchst. Das ist die beste Position, in der du dich befinden kannst, bevor du eine benutzerdefinierte Lösung in Auftrag gibst.This is the best possible position to be in before commissioning a custom build.
- Die SaaS-Preise im großen Maßstab sind wirklich teurer als Eigenentwicklung. Rechne es für deine prognostizierte Nutzung im dritten Jahr durch. Manchmal gewinnt Custom-Build rein wirtschaftlich.Do the maths at your projected Year 3 usage. Sometimes custom wins on pure economics.
---
Wann der Kauf eindeutig die richtige Entscheidung ist
Ebenso gibt es Situationen, in denen Kaufen offensichtlich ist:
- Du bist vor der Umsatzphase oder vor Product-Market-Fit. Punkt.
- Die Funktion ist Commodity-Infrastruktur — Email, Zahlungen, Authentifizierung, Speicher, 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 hinzufügen: Wenn du als Gründer baust, um eine schwierigere geschäftliche Entscheidung zu vermeiden, lohnt es sich, das zu überprüfen. Custom Builds können eine sehr teure Form von Prokrastination sein.to avoid making a harder business decision, that's worth examining. Custom builds can be a very expensive form of procrastination.
---
Der Hybrid-Ansatz (oft der intelligenteste Weg)
Hier ist das, worüber niemand genug spricht: Bauen und Kaufen schließen sich nicht gegenseitig aus.
Der pragmatischste Ansatz, den ich wiederholt funktionieren sehen habe, ist dieser — kaufe die Standard-Komponenten aggressiv ein, und baue die dünne Schicht der differenzierten 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 Development, nicht sechs Monate.
Bei Seahawk haben wir Hunderte von Websites auf WordPress — einer gekauften Plattform — mit Custom Plugins gebaut, die wirklich neuartige Dinge tun. Die Plattform kümmert sich um die 80%. Wir bauen die 20%, die wichtig sind. Es ist langweilige Ratschläge. Es ist auch der Ratschlag, der 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. Fang damit an, dass du einen ernsthaften Nachmittag aufwendest — ich meine vier oder fünf Stunden, nicht zwanzig Minuten — und mappt jedes SaaS-Produkt in deiner Kategorie. Wenn du das getan hast und nichts deckt deine Kernanforderung ab, frag dich selbst, ob diese Anforderung wirklich jetzt notwendig ist oder ob es eine nice-to-have ist, die du zu einem Blocker hochgestuft hast. Wenn es wirklich notwendig und wirklich unerfüllt ist, das ist ein Signal, das man ernst nehmen sollte.necessary right nowor whether it's a nice-to-have you've elevated into a blocker. If it's truly necessary and truly unserved, that's a signal worth taking seriously.
Was ist das Minimum-Team, das du brauchst, um responsibel Custom Software zu besitzen?
Mindestens: ein Entwickler, der die Codebasis tief versteht, und entweder ein zweiter Entwickler oder eine beauftragte Agentur, die einspringen kann, wenn dieser nicht verfügbar ist. Custom Software mit einem einzelnen Freelancer und ohne Backup ist eine fragile Position. Ich habe gesehen, wie das echte operative Schäden verursacht hat, wenn diese eine Person nicht erreichbar ist — 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 unternutzt. 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 initialen Entwicklungskosten. Der Haken: Du betreibst immer noch die Infrastruktur und brauchst immer noch jemanden technisch Versierten, um sie zu verwalten. Es ist nicht kostenlos — es ist nur billiger zum Starten.Metabasefor analytics, Directus for headless CMS, or ERPNext for operations give you the flexibility of custom software with significantly lower initial build cost. The catch: you're still owning infrastructure and you still need someone technical to manage it. It's not free — it's just cheaper to start.
---
Ein abschließender Gedanke
Die Frage „Eigenentwicklung versus Zukauf" hat keine universelle Antwort. Sie hat deine Antwort, spezifisch für deine Phase, dein Team, deine Wettbewerbsposition und was du bisher wirklich validiert hast.youranswer, specific to your stage, your team, your competitive position, and what you've actually validated so far.
Wogegen ich ankämpfen würde, ist die Romantik rund um Eigenentwicklung. Custom Software ist nicht inhärent ernsthafter, skalierbarer oder beeindruckender als ein gut konfigurierter SaaS-Stack. Der Gründer aus meinem Beispiel am Anfang? Er baute letztendlich etwas wirklich Custom — aber erst, nachdem achtzehn Monate mit Invoice Ninja ihm genau gezeigt hatten, was seine Kunden wirklich brauchten. Der Build war besser für das Warten.
Beginne mit der langweiligen Option. Verdiene dir das Recht, etwas Neues zu bauen.