E-Commerce-Suche: Spezialisierter SaaS-Anbieter oder Eigenentwicklung?

"Das können wir doch selbst bauen." Dieser Satz fällt in fast jedem zweiten Evaluierungsgespräch. Und auf den ersten Blick klingt er vernünftig. Die eigene IT-Abteilung ist kompetent. Open-Source-Tools wie Elasticsearch sind frei verfügbar. LLM-APIs lassen sich in wenigen Tagen anbinden. Warum also monatlich für eine externe Lösung zahlen?

Die Antwort liegt nicht in der Machbarkeit. Natürlich kann ein gutes Entwicklerteam eine Suchfunktion bauen. Die Frage ist: Zu welchem Preis? Mit welchem Zeitaufwand? Und vor allem: Auf Kosten welcher anderen Projekte?

Dieser Artikel rechnet die Eigenentwicklung einer E-Commerce-Suche gegen eine spezialisierte SaaS-Lösung durch. Nicht theoretisch, sondern mit konkreten Zahlen, realistischen Szenarien und den versteckten Kosten, die in keinem Prototyp sichtbar sind.

Hinweis: Wenn Sie sich eher für die Frage interessieren, ob generische KI-Tools wie ChatGPT oder Claude Ihre Shop-Suche ersetzen können, lesen Sie unseren Artikel Generische KI vs. spezialisierte E-Commerce-Suche.

Die TCO-Rechnung: Was Eigenentwicklung wirklich kostet

Die meisten Build-vs-Buy-Entscheidungen scheitern an einer unvollständigen Kostenrechnung. Das Entwicklerteam schätzt den initialen Buildaufwand. Was fehlt: die laufenden Kosten, die den Bau um ein Vielfaches übersteigen.

Initiale Entwicklung

Eine produktionsreife E-Commerce-Suche ist kein Wochenendprojekt. Die Kernkomponenten:

Bei einem Team aus zwei Senior-Backend-Entwicklern (Durchschnittsgehalt in Deutschland: ca. 75.000 € brutto/Jahr, Arbeitgeberkosten mit Lohnnebenkosten ca. 95.000 €) plus einem Frontend-Entwickler und anteiligem Product Owner ergibt sich ein realistisches Bild:

Initiale Entwicklungskosten: 250.000 – 400.000 €

Und das ist die Untergrenze. Ohne UX-Design, ohne externe Beratung, ohne Puffer für die Dinge, die erst im Live-Betrieb sichtbar werden.

Laufende Kosten: Der teure Teil

Studien zeigen: Über 65 % der Gesamtkosten eines Softwareprojekts fallen in der Wartungsphase an. Bei einer E-Commerce-Suche umfasst das:

Die 3-Jahres-Rechnung

In diesen Zahlen fehlt noch der größte Posten: die Opportunitätskosten.

Opportunitätskosten: Was Ihre Entwickler stattdessen bauen könnten

Jeder Entwickler, der an der Suchfunktion arbeitet, arbeitet nicht an Ihrem Kernprodukt. Nicht an der Checkout-Optimierung. Nicht an der App. Nicht an der Internationalisierung. Nicht an den Features, die Ihren Shop von der Konkurrenz abheben.

Für einen Online-Retailer mit >5 Mio. € Umsatz ist die Suchfunktion geschäftskritisch. Aber sie ist nicht das Kerngeschäft. Ihr Kerngeschäft ist Sortiment, Kundenbeziehung, Marke, Logistik. Die Suche ist Infrastruktur. Sie muss funktionieren, performant und intelligent sein. Aber sie muss nicht selbst gebaut werden.

Die Build-vs-Buy-Regel, die sich in der Praxis bewährt hat: Wenn eine bestehende Lösung mindestens 60 % Ihrer Anforderungen erfüllt, kaufen Sie. Bei spezialisierten SaaS-Anbietern für E-Commerce-Suche liegt die Abdeckung typischerweise bei 90 % und mehr.

Was in der Prototyp-Phase niemand sieht

Der gefährlichste Moment in einem Eigenentwicklungsprojekt ist die erfolgreiche Demo. Der Prototyp funktioniert. Die Suche liefert Ergebnisse. Das Board ist beeindruckt.

Was der Prototyp nicht zeigt:

1. Suggest, Suchergebnisse und Kategorielisten sind drei verschiedene Systeme

Eine E-Commerce-Suche ist nicht eine Suchleiste. Es sind mindestens drei eigenständige Systeme, die zusammenspielen müssen:

• Suggest/Autocomplete reagiert bei jedem Tastendruck, liefert Produktvorschläge, Kategorien und Suchbegriffe in Echtzeit

• SERP (Search Engine Results Page) berechnet Relevanz, wendet Merchandising-Regeln an, baut dynamische Facetten auf

• Kategorielisten sortieren und filtern Tausende Produkte nach komplexen Attributlogiken, Verfügbarkeiten und Geschäftsregeln

Jedes dieser Systeme hat eigene Performance-Anforderungen, eigene Datenmodelle und eigene Edge Cases. Der Prototyp zeigt typischerweise nur eins davon.

2. Echtzeit-Datensynchronisation ist ein eigenes Engineering-Problem

Preise ändern sich. Produkte werden deaktiviert. Varianten gehen aus dem Lager. Kampagnen starten um 8:00 Uhr morgens. All das muss in Millisekunden in der Suche ankommen. Nicht in Minuten. Nicht mit einem nächtlichen Batch-Import.

Eine Delta-Update-Pipeline, die Daten aus ERP, PIM, CMS und Shopsystem in Echtzeit aggregiert, ist ein eigenständiges Infrastrukturprojekt. Es erfordert Fachwissen in Datenverarbeitung, Streaming-Architekturen und Fehlerresilienz.

3. B2B-Logiken multiplizieren die Komplexität

Sobald Ihr Shop B2B-Funktionen hat, explodiert die Komplexität:

• Kundenspezifische Preise (Staffelpreise, Rahmenverträge, individuelle Konditionen)

• Sichtbarkeitsregeln (nicht jeder Kunde darf jedes Produkt sehen)

• Variantenlogiken (ein Produkt, 200 Varianten, 15 Attribute, kundenspezifisch gefiltert)

• Gruppenlogiken (Konzern sieht andere Preise als Einzelhändler)

Standardsuchen und Prototypen kennen keine dieser Logiken. Spezialisierte Infrastruktur wurde genau dafür entwickelt.

4. Performance unter Last ist ein anderes Spiel

50 Suchanfragen pro Minute in der Demo sind etwas anderes als 5.000 gleichzeitige Anfragen am Black Friday. Autoscaling, Caching-Strategien, Fallback-Mechanismen, Rate Limiting. All das fällt nicht vom Himmel. Es wird über Jahre entwickelt und unter realen Lastszenarien gehärtet.

Der direkte Vergleich: SaaS-Infrastruktur vs. Legacy-Suche vs. Eigenentwicklung

Die fünf häufigsten Argumente für Eigenentwicklung. Und warum sie nicht halten.

"Wir haben volle Kontrolle."

Stimmt. Sie haben auch die volle Verantwortung. Für jeden Bug. Für jedes Performance-Problem. Für jeden DSGVO-Verstoß. Für jede Ausfallminute. 24/7/365.

Moderne SaaS-Infrastruktur bietet API-First-Ansätze mit vollem Zugriff auf Konfiguration, Relevanz-Regeln und Merchandising-Logik. Kontrolle ohne die Last des Betriebs.

"Wir sparen die Lizenzkosten."

Die Rechnung ignoriert, dass ein einziger Vollzeit-Entwickler für Wartung jährlich mehr kostet als die meisten SaaS-Lizenzen. Dazu kommen Hosting, Monitoring, Skalierung und der ständige Kampf gegen Technical Debt.

"Unsere Anforderungen sind zu speziell."

B2B-Preislogiken, kundenspezifische Sichtbarkeiten, komplexe Variantenstrukturen. Genau dafür existieren spezialisierte Anbieter. Was für Ihr Unternehmen einzigartig scheint, ist für einen Anbieter mit 50+ Mid-Enterprise-Kunden ein gelöstes Problem.

"Wir wollen keine Abhängigkeit von einem Anbieter."

Vendor-Lock-in ist ein berechtigtes Bedenken. Die Gegenrechnung: Eigenentwicklung erzeugt Abhängigkeit von internen Wissensträgern. Wenn der Lead-Entwickler kündigt, steht die gesamte Suchinfrastruktur auf dem Spiel. Bei einem SaaS-Anbieter ist das Wissen im Produkt, nicht in einzelnen Köpfen.

"KI-APIs machen das heute einfach."

Einen Prototyp mit einer LLM-API bauen? Absolut machbar. Produktionsreif betreiben? Eine andere Geschichte. Wer sich für die technischen Details interessiert, warum rohe KI-APIs keine fertige Shop-Suche ersetzen, findet die Antwort in unserem Artikel Generische KI vs. spezialisierte E-Commerce-Suche.

Was Kunden berichten, die beide Wege kennen

"Die Produktsuche ist kein Extra. Sie ist der erste Kontakt mit unseren Kund:innen. Mit BatteryIncluded haben wir die Kontrolle zurückgewonnen: bessere Relevanz, weniger Pflege, mehr Wirkung. Jetzt kann der Vertrieb die Suche ohne IT steuern, Marketingaktionen greifen durch – und der Shop wirkt wie aus einem Guss. Eine strategisch richtige Entscheidung."

G.Wurm GmbH + Co. KG

"BatteryIncluded.ai ist genau das, was man sich von moderner E-Commerce-Technologie wünscht: blitzschnelle Suche auch bei über 50.000 Produkten, volle Anpassbarkeit für komplexe Anforderungen und ein Support, der nicht nur reagiert, sondern wirklich versteht. Stabil, skalierbar, zukunftssicher."

Österreichischer Bundesverlag Schulbuch GmbH & Co. KG

Beide Unternehmen hätten die Ressourcen gehabt, eine eigene Lösung zu bauen. Beide haben sich bewusst dagegen entschieden. Nicht weil sie es nicht konnten. Sondern weil es nicht sinnvoll war.

Checkliste: Eigenentwicklung oder SaaS?

Beantworten Sie diese fünf Fragen ehrlich:

1. Haben Sie mindestens 2 Senior-Entwickler, die dauerhaft an der Suche arbeiten können? Nicht für den Prototyp. Dauerhaft. Für Wartung, Weiterentwicklung, Skalierung.

2. Liegt Ihre Kernkompetenz in Suchtechnologie? Wenn Ihr Unternehmen Schuhe, Bücher oder Industrieteile verkauft: Suchtechnologie ist nicht Ihr Kerngeschäft. Konzentrieren Sie Ihre Ressourcen auf das, was Sie besser können als alle anderen.

3. Können Sie 9-14 Monate auf eine produktionsreife Lösung warten? In dieser Zeit verlieren Sie Conversion. Jeden Tag. Eine SaaS-Lösung ist in 2-6 Wochen live.

4. Haben Sie einen Plan für Lastspitzen? Black Friday, Cyber Monday, saisonale Peaks. Ihre Infrastruktur muss das Zehnfache des Normalbetriebs aushalten. Ohne Vorlaufzeit.

5. Wie reagieren Sie, wenn Ihr Lead-Entwickler kündigt? Wenn das Suchwissen in einem Kopf steckt, haben Sie ein Risiko. Kein Anbieter-Lock-in. Ein People-Lock-in.

Wenn Sie mehr als zwei Fragen mit "Nein" oder "Unsicher" beantworten, ist eine spezialisierte Lösung die wirtschaftlichere Entscheidung.

Fazit: Build vs. Buy ist keine Technologiefrage. Es ist eine Ressourcenfrage.

Die Frage ist nie, ob Ihr Team eine Suche bauen kann. Die Frage ist, ob es das tun sollte.

Eigenentwicklung bindet zwei bis drei hochqualifizierte Entwickler, kostet im Aufbau 250.000 bis 400.000 € und erzeugt laufende Kosten von über 100.000 € pro Jahr. Die Time-to-Value liegt bei 9 bis 14 Monaten. Jeder Tag ohne optimierte Suche ist ein Tag mit verlorener Conversion.

Spezialisierte SaaS-Infrastruktur liefert dieselbe Funktionalität in Wochen statt Monaten. Mit 25+ Jahren E-Commerce-Erfahrung im Produkt. Mit Echtzeit-Datensynchronisation, DSGVO-konformer KI, Merchandising-Engine und einem Team, dessen einzige Aufgabe es ist, E-Commerce-Suche besser zu machen. Jeden Tag.

Die besten Entwicklerteams erkennt man nicht daran, dass sie alles selbst bauen. Sondern daran, dass sie wissen, wann sie es nicht tun sollten.

Zu Ihrer kostenlosen Demo

Verwandte Artikel:

• Generische KI vs. spezialisierte E-Commerce-Suche

• Was ist semantische Suche?

• Shopware Suche optimieren

• KI-Suche im E-Commerce