Ein Kunde rief mich 2021 an -- echte Panik in der Stimme. Er hatte £140.000 über vierzehn Monate ausgegeben, um eine eigene Rechnungsplattform zu bauen. Sein Dev-Team hatte vielleicht 60% der Anforderungen umgesetzt. Und irgendwann im elften Monat hatte er herausgefunden, dass Invoice Ninja existiert, Open-Source ist und 90% von dem, was er brauchte, sofort funktioniert. Kostenlos.Invoice Ninja existed, was open-source, and did 90% of what he needed out of the box. For free.
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.Buy SaaS until the subscription tax, data ownership, or workflow mismatch genuinely bites; build custom when the tool is core to how the business wins.
Dieser Anruf verfolgt mich ein bisschen. Weil ich ehrlich gesagt auch den gegenteiligen Fehler gemacht habe. Seahawk hatte 2019 ein Projekt, bei dem wir acht Monate damit verbracht haben, fünf verschiedene SaaS-Tools zusammenzuflicken -- Airtable, Zapier, Typeform, HubSpot und ein eigenes Webflow CMS -- um einen Client-Workflow zu verwalten, der im Rückblick durch einen Custom Build für £15.000 sauber und dauerhaft gelöst worden wäre. Am Ende zahlten wir ungefähr £900/Monat an kombinierten Abos. Rechne das mal über drei Jahre hoch.
Keine der beiden Extremen ist automatisch richtig. Und wer dir eine saubere Regel verkauft -- "baue immer", "baue nie" -- verkauft dir etwas. Hier ist also das echte Framework, das ich nutze, wenn ein Gründer sich zu mir setzt 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 sitzt die Differenzierung in meinem Produkt? Wenn das, das du bauen willst, zentral für deinen Wettbewerbsvorteil ist -- der Grund, warum Kunden dich dem nächsten Tab im Browser vorziehen -- dann macht Bauen wahrscheinlich Sinn. Wenn es Infrastruktur, Admin oder Commodity-Funktionen sind, ist Kaufen in realen Zahlen fast sicher günstiger.reason customers 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 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.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 bist dafür am Haken, bis du die Sache vom Netz nimmst.Not a one-off. You're on the hook forever unless you sunset the thing.
- Security-Patches. Ein SaaS-Vendor kümmert sich darum. Du baust, du besitzt es, inklusive der 2-Uhr-morgens-Alerts.A SaaS vendor handles this for you. You build it, you own it, including the 2am alerts.
- Onboarding neuer Devs. Wenn dein Lead Engineer geht, muss die nächste Person deinen Codebase lernen. Das sind Wochen an billbaren Stunden.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 Scope expandiert. Kosten folgen.Stakeholders see a custom tool and assume it can do everything. Scope expands. Costs follow.
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, der CHAOS Report der Standish Group zeigt seit Jahrzehnten, dass Software-Projekte ihre Budgets in alarmierendem Maße überziehen. Die Quote liegt bei etwa 45-50% der Projekte, die "herausfordernd" oder geradezu scheitern. Das ist kein Grund, nie zu bauen -- es ist ein Grund, mit offenen Augen reinzugehen.Standish Group's CHAOS Report has 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 billig aus, bis es das nicht mehr ist.
Der £49/Monat Plan, der zu Jahresbeginn vernünftig schien, hat die lustige Angewohnheit, bis Jahr drei zu £490/Monat zu werden -- sobald du auf einem höheren Tier bist, hast du Seats hinzugefügt, und der Vendor hat eine "Pricing-Umstrukturierung" durchgeführt (lies: Preiserhöhung). Ich habe das bei Clients bei Salesforce, Intercom und Mixpanel beobachtet. Es ist nicht böse gemeint. 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.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 via Zapier irgendwie integrieren, sind kein System. Das ist eine Haftung. Eine API-Abschaltung und schon fängt alles 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. 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.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 -- für Commodity-Funktionen ist SaaS fast immer die richtige Wahl. E-Mail-Versand? Postmark oder SendGrid. Zahlungen? Stripe, logisch. Auth? Auth0 oder Clerk. Niemand sollte 2024 seinen eigenen Payment Processor bauen.Postmark or 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?
Wenn ja -- wenn das die Sache ist, die dein Produkt wirklich unterschiedlich macht -- ist Bauen ernsthaft in Erwägung zu ziehen. Wenn nein, stoppe hier. Kaufe.
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 investiere mindestens zwei Stunden in die Recherche des SaaS-Markts, bevor ich jemals einen Custom Build empfehlen würde. Product Hunt und G2 sind hier wirklich nützlich -- nicht als Evangelium, aber als Startinventar.Product Hunt and G2 are genuinely useful here -- not as gospel but as a starting inventory.
Frage 3: Was ist deine realistische Time-to-Value?
Ein SaaS-Tool kann heute live gehen. Ein Custom Build braucht mindestens Wochen, meistens Monate. Wenn Geschwindigkeit zählt -- und in frühen Startups ist das fast immer der Fall -- kaufen dir Zeit, um herauszufinden, 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 überredeten sie, zuerst einen White-Label-API-Layer zu nutzen (sie verwendeten 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 die halbe Reichweite -- und war doppelt so gut -- weil sie in der Produktion gelernt hatten, nicht in einem Specification-Dokument.Route4Me as 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?
Weil es kaputt gehen 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, sitzt du in Schwierigkeiten. Das ist nicht hypothetisch -- ich habe Gründer gesehen, die wochenlang mit kaputtem Custom Software steckengeblieben sind, weil ihr Freelance-Developer in den Urlaub gegangen 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 Kern-IP ist die Software selbst. Wenn du ein SaaS-Produkt verkaufst, kannst du das, was du verkaufst, nicht outsourcen.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 mögliche Position, bevor du einen Custom Build in Auftrag gibst.This is the best possible position to be in before commissioning a custom build.
- 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.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 pre-revenue oder pre-product-market fit. Punkt.
- Die Funktion ist Commodity-Infrastruktur -- E-Mail, 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.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 die Sache, über die niemand ausreichend spricht: Build und Buy schließen sich nicht gegenseitig aus.
Der pragmatischste Ansatz, den ich wiederholt funktionieren sehen habe, ist dieser -- kaufe die Commodity-Teile aggressiv, und baue die dünne Schicht differenzierter Logik oben drauf. 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 wirklich neuartige Dinge tun. Die Plattform kümmert sich um die 80%. Wir bauen die 20%, die zählen. Es ist langweilige Beratung. Es ist auch die Beratung, die am häufigsten funktioniert hat.WordPress -- a bought platform -- with custom plugins that do genuinely novel things. The platform handles the 80%. We build the 20% that matters. It's boring advice. It's also the advice that's worked most often.
---
FAQ
Woher weiß ich, ob mein Use-Case wirklich einzigartig genug ist, um einen Custom Build zu rechtfertigen?
Ehrliche Antwort: die meisten nicht. Fang damit an, einen ernsthaften Nachmittag zu verbringen -- ich meine vier oder fünf Stunden, nicht zwanzig Minuten -- jedes SaaS-Produkt in deiner Kategorie zu kartografieren. Wenn du das getan hast und nichts deine Kernvoraussetzung abdeckt, frag dich, ob diese Voraussetzung wirklich jetzt notwendig ist oder ob es ein Nice-to-Have ist, das du zu einem Blocker hochgestuft hast. Wenn es wirklich notwendig und wirklich unerschlossen ist, ist das ein Signal, das es wert ist, ernst genommen zu werden.necessary right now or 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 Sie benötigen, um Custom Software verantwortungsvoll zu betreiben?
Mindestens: ein Entwickler, der die Codebase tief versteht, und entweder ein zweiter Entwickler oder eine beauftragte Agentur, die ausfall, wenn er nicht verfügbar ist. Custom Software mit einem einzelnen Freelancer und ohne Backup zu besitzen ist eine fragile Position. Ich habe gesehen, dass es echten operativen Schaden verursacht hat, wenn diese eine 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 initialen Build-Kosten. Der Haken: du besitzt immer noch Infrastruktur und brauchst immer noch jemanden Technischen, um sie zu verwalten. Es ist nicht kostenlos -- es ist nur günstiger, um zu starten.Metabase for 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 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.your answer, specific to your stage, your team, your competitive position, and what you've actually validated so far.
Wogegen ich argumentieren würde, ist die Verklärung des Selberbauens. Custom Software ist nicht per se ernster, skalierbarer oder beeindruckender als ein gut konfigurierter SaaS-Stack. Der Gründer im Rechnungswesen, den ich anfangs erwähnt habe? Er baute am Ende tatsächlich etwas Maßgeschneidertes -- aber erst nachdem er achtzehn Monate lang Invoice Ninja nutzte und damit genau lernte, was seine Kunden wirklich brauchten. Das Ergebnis war besser für das Warten.
Beginne mit der langweiligen Option. Verdiene dir das Recht, etwas Neues zu bauen.