„Ich kann an einem Wochenende eine Suchmaschine erstellen. Es ist nur ein invertierter Index.“ „Ich kann an einem Tag ein Auth-System erstellen. Es ist nur ein JWT.“ „Ich kann ein CMS in einer Woche erstellen. Es ist einfach CRUD.“

Dies ist der Sirenengesang des Ingenieurs. Es ist technisch gesehen wahr. Sie können den Prototyp an einem Wochenende bauen. Aber Sie können das Produkt nicht an einem Wochenende erstellen. Weil ein Produkt Folgendes umfasst:

99,99 % Verfügbarkeits-SLA.
Sicherheitsaudits (SOC2).
Edge-Caching.
Abwärtskompatibilität.
Dokumentation.

Die Entscheidung „Build vs. Buy“ ist der wichtigste Hebel, den ein CTO anwendet. Wenn Sie es falsch machen, verbringt Ihr Team 2026 damit, ein fehlerhaftes, selbst entwickeltes CMS zu patchen, anstatt Funktionen auszuliefern, die Geld einbringen.

Bei Maison Code nutzen wir für diesen Aufruf einen strengen finanziellen und strategischen Rahmen.

Warum Maison Code dies bespricht

Wir werden oft beauftragt, „selbst angebaute“ Verschmutzungen zu beseitigen. Ein Kunde baute 2018 seine eigene E-Commerce-Plattform mit PHP auf. Jetzt ist der leitende Entwickler gegangen. Die Plattform ist unsicher. Es ist langsam. Die Kosten für die Migration zu Shopify betragen 100.000 US-Dollar. Die Kosten für den Aufenthalt betragen 500.000 US-Dollar pro Jahr für die Wartung. Wir helfen Führungskräften, diese Fallen zu vermeiden. Wir haben keine Angst zu sagen: „Stellen Sie uns nicht ein. Kaufen Sie stattdessen SaaS.“

1. Das Kern- vs. Kontext-Framework (Geoffrey Moore)

Geoffrey Moore (Crossing the Chasm) hat dies perfekt definiert. Jede Aktivität in Ihrem Unternehmen fällt in einen Quadranten:

	Mission Critical	Nicht geschäftskritisch
Differenzierer	KERN (Build)	Innovation (Experiment)
Parität	KONTEXT (Kaufen)	Verschwendung (Stopp)

Die „Kontext“-Falle

Die meisten „Build“-Entscheidungen sind tatsächlich geschäftskritischer Kontext.

Zahlungen: Unverzichtbar? Ja. Unterscheidungsmerkmal? Nein. (Niemand kauft bei Ihnen, weil Ihr Zahlungsformular einzigartig ist).
Suche: Unverzichtbar? Ja. Unterscheidungsmerkmal? Nein. (Es sei denn, Sie vertreten Google).
E-Mail: Unverzichtbar? Ja. Unterscheidungsmerkmal? Nein.

Regel: Wenn es sich um „Kontext“ handelt, müssen Sie KAUFEN. Verwenden Sie Stripe. Verwenden Sie Algolia. Benutze Klaviyo. „Kontext“ aufzubauen bedeutet Wertvernichtung. Sie verbringen knappe Entwicklungsstunden damit, ein Produkt nachzubilden, das Ihr Konkurrent für 500 US-Dollar pro Monat kauft.

Das „Kern“-Mandat

Wenn es Kern ist, müssen Sie BAUEN.

Uber: Der Versandalgorithmus ist Core. Sie können „Dispatch-as-a-Service“ nicht nutzen.
Amazon: Die Lagerlogistiksoftware ist Core.
Netflix: Die Empfehlungs-Engine ist Core.

Wenn Sie Ihren Kern kaufen, haben Sie keinen Burggraben. Sie sind Wiederverkäufer des geistigen Eigentums einer anderen Person.

2. Der Total Cost of Ownership (TCO)-Rechner

Ingenieure unterschätzen die Baukosten um den Faktor 10. Sie berechnen die „Entwicklungszeit“. Sie ignorieren „Lebenszykluskosten“.

Nehmen wir an, Sie möchten einen „Store Locator“ erstellen. Build-Schätzung: „Es ist nur die Google Maps API. 3 Tage Entwicklung.“ Kosten: 2.000 €.

Die Realität (3-Jahres-TCO):

V1-Build: 5 Tage (Realitätsprüfung). 4.000 €.
Hosting: Serverlose Funktionen + DB. 50 €/Monat -> 1.800 €.
Wartung (Jahr 1): Google aktualisiert die API. Breaking Change. 2 Tage fix. 1.600 €.
Funktionsanfrage (Jahr 1): Marketing möchte „Nach Offenheit filtern“. 3 Tage. 2.400 €.
Sicherheitspatch (Jahr 2): Abhängigkeitslücke. 1 Tag. 800 €.
Onboarding: Neue Entwickler müssen Ihren benutzerdefinierten Spaghetti-Code lernen. 2.000 €.

Gesamtbaukosten: 12.600 €. Kaufkosten (z. B. Stockist.co): 20 €/Monat -> 720 €.

Urteil: Sie haben 11.880€ Shareholder Value verbrannt, um einen Store Locator aufzubauen, der deutlich schlechter ist als die SaaS-Version.

3. Der „hybride“ Ansatz (Composable)

Es handelt sich selten um eine binäre Entscheidung. Die moderne „Composable Architecture“ ermöglicht es Ihnen, den Motor zu kaufen und das Auto zu bauen.

Beispiel: CMS (Content Management)

Kaufen (Headless CMS): Sanity/Contentful. Sie kümmern sich um die Datenbank, die APIs, das Bild-CDN, den Rich-Text-Editor, die kollaborative Bearbeitung und die Revisionen.
Build (Frontend): Next.js / Hydrogen. Sie bauen die Präsentationsschicht auf.

Sie kaufen das „Hard Engineering“ (Infrastruktur) und bauen die „User Experience“ (Differenzierung) auf.

Beispiel: Suche

Buy (Algolia): Sie kümmern sich um die Indizierung, die Tippfehlertoleranz, die Synonyme und das Sharding.
Erstellen (UI): Sie erstellen die Suchleiste, die Sofortvorschau und die Ergebniskarten.

4. Vendor Lock-In: Der Boogeyman

„Wenn ich Auth0 verwende, bin ich eingesperrt! Was ist, wenn die Preise steigen?“ Das ist eine berechtigte Angst. Aber vergleichen Sie es mit Technical Debt Lock-In. Wenn Sie Ihre eigene Authentifizierung erstellen, sind Sie an Ihren eigenen Code gebunden. Und im Gegensatz zu Auth0 verfügt Ihr Code nicht über ein Team von 500 Sicherheitsingenieuren, die Zero-Day-Exploits patchen.

Abwehrstrategie: Das Adaptermuster. Rufen Sie „auth0.login()“ nicht überall in Ihrer App auf. Wickeln Sie es in „lib/auth.ts“ ein. Wenn Auth0 die Preise um das Zehnfache erhöht, schreiben Sie „lib/auth.ts“ so um, dass es auf Clerk oder Firebase verweist. Die Umstellungskosten betragen 1 Woche. Der Wert der dreijährigen Nutzung von Auth0 ist immens.

5. Wartung: Der stille Killer

Code ist eine Belastung. Jede Codezeile, die Sie schreiben, ist eine Zeile, die Sie für immer debuggen, testen, aktualisieren und sichern müssen. Zero-Code ist der ideale Zustand. Die besten Ingenieure sind diejenigen, die den wenigsten Code schreiben, um das Problem zu lösen.

„Die Zivilisation schreitet voran, indem sie die Zahl wichtiger Operationen erweitert, die wir ausführen können, ohne darüber nachzudenken.“ — Alfred North Whitehead

SaaS ermöglicht es Ihnen, „nicht an die E-Mail-Zustellung zu denken“. Oder Zahlungen. Oder Backups. Dies gibt Ihrem Gehirn die Freiheit, über den Kundenwert nachzudenken.

6. Der Irrtum über die Migrationskosten

„Wenn wir Algolia kaufen, wird die Integration Wochen dauern!“ „Wenn wir es selbst bauen, können wir noch heute mit dem Codieren beginnen!“ Dies ist der Irrtum der Migrationskosten. Die Integration ist mit einmaligen Kosten verbunden. Der Bau kostet ein Leben lang. Integration: 2 Wochen. Build: 3 Monate (MVP) + unbegrenzte Wartung. Wenn Sie SaaS kaufen, erhalten Sie außerdem „Best Practices“ sofort einsatzbereit. Sie erhalten nicht nur eine Suchmaschine. Sie erhalten „Synonymmanagement“, „Analytics“, „A/B-Testing“. Wenn Sie es bauen, müssen Sie diese Funktionen selbst erfinden (was Sie nicht tun werden, also ist Ihr Produkt schlecht).

7. Fallstudie: Die 1-Millionen-Dollar-Suchmaschine

Wir haben einen Kunden geprüft, der seinen eigenen ElasticSearch-Cluster aufgebaut hat. Team: 3 leitende Ingenieure (600.000 USD/Jahr). Infrastruktur: AWS Large Instances (50.000 USD/Jahr). Management: 20 % der CTO-Zeit. Ergebnis: Die Suche war… okay. Es wurde nicht gut mit Tippfehlern umgegangen. Es wurde nicht nach Beliebtheit geordnet. Konkurrent: Gebrauchtes Algolia (30.000 €/Jahr). Vergleich:

Kundenkosten: 1 Mio. USD+ über 3 Jahre.
SaaS-Kosten: 90.000 € über 3 Jahre.
Qualität: SaaS war 10x besser. So sterben Unternehmen. Sie verschwenden Kapital für nicht differenzierende Technik.

8. Die Exit-Strategie (Datenportabilität)

Fragen Sie beim SaaS-Kauf immer: „Wie gehe ich aus?“ Wenn Sie Contentful verwenden, können Sie Ihre Inhalte als JSON exportieren? (Ja). Können Sie Ihre Kunden exportieren, wenn Sie Shopify nutzen? (Ja). Wenn die Antwort „Nein“ lautet, kaufen Sie nicht; Du bist eine Geiselnahme. Wir schreiben für jeden Anbieter ein Datenportabilitätsaudit vor. Wir simulieren einen „Exit“, bevor wir den Vertrag unterzeichnen. „Alle Daten herunterladen. In einer neutralen Datenbank wiederherstellen.“ Wenn dies > 1 Woche dauert, unterschreiben wir nicht.

9. Fazit: Die Entscheidungsmatrix

Führen Sie diese Prüfung durch, bevor Sie eine einzelne Codezeile schreiben:

Ist diese Funktion einzigartig für unser Geschäftsmodell?

Nein -> Kaufen.

Gibt es eine SaaS-Lösung, die 80 % der Anforderungen abdeckt?

Ja -> Kaufen.

Sind die Kosten für SaaS höher als die Kosten für 1 Techniker/Jahr?

Nein -> Kaufen.

Nur wenn die Antwort „Ja, Nein, Ja“ lautet -> Build.

Ihre Aufgabe als CTO besteht nicht darin, Code zu schreiben. Es geht darum, Kapital effizient zu verteilen, um einen ROI zu generieren. Der Kauf von SaaS ist normalerweise die Aktivität mit dem höchsten ROI, die Sie durchführen können.

Brauchen Sie eine ehrliche Prüfung?

Erfinden Ihre Ingenieure das Rad neu?

Stellen Sie unsere Architekten ein.