Die Frage "Bauen wir das selbst oder kaufen wir es?" ist im E-Commerce-Frontend allgegenwartig - und wird selten gut beantwortet. Meistens entscheidet die interne Praferenz ("wir haben gute Entwickler"), die Erfahrung des letzten Projekts ("das Custom-Build war ein Desaster") oder der Druck des nachsten Launch-Termins. Selten entscheidet ein durchgerechneter Business Case.

Dieser Beitrag liefert diesen Business Case. Nicht als Verkaufsargument, sondern als Entscheidungsrahmen: Wann ist das Bauen eigener Storefront-Komponenten die richtige Wahl, wann gewinnen production-ready Growth Kits wie die Laioutr Growth Kit-Sets? Und wie rechnet sich die Entscheidung uber drei bis funf Jahre?

Vorweg: Es gibt keine universell richtige Antwort. Aber es gibt eine Reihe von Faktoren, die die Antwort fur dein Team stark determinieren - und die meisten Teams vernachlassigen mindestens zwei davon.

Was genau verglichen wird

Wir reden hier nicht uber die Entscheidung zwischen einer proprietaren Plattform und einem Open-Source-Stack. Wir reden uber eine spezifischere Frage innerhalb eines Composable Commerce-Setups:

Hast du einen flexiblen Frontend-Layer (z.B. Laioutr als FMP) und entscheidest, ob du die UI-Komponenten dafur selbst baust oder fertige, production-ready Component Sets (Growth Kits) nutzt, die auf dieser Plattform laufen?

Das ist die relevante Entscheidung fur Teams, die:

• einen Composable-Commerce-Stack aufbauen oder migrieren
• ihre Component Library erneuern oder skalieren wollen
• ein neues Vertikal (B2C, SaaS, Marketplace) mit einem Launch-Termin in den nachsten 90 Tagen aufbauen mussen

Die Kosten des Custom-Builds, die niemand vorab rechnet

Initialaufwand ist der kleinste Posten

Wenn Entwicklungsteams "selbst bauen" sagen, denken sie zuerst an Stundensatze und Sprint-Planung. Ein realistisches UI-Component-Set fur einen mittelgrossen E-Commerce-Storefront umfasst typischerweise 40-80 Komponenten: Navigation, Produktliste, Produktdetail, Cart, Checkout-Steps, Filter, Search, CMS-Slots, Footer, Modals, Form-Elemente, Toast-Notifications und eine handvoll Layout-Scaffolds.

Bei einem Senior-Frontend-Entwickler mit einem Tagessatz von 800-1.000 Euro und einer realistischen Schatung von 2-3 Tagen pro Komponente (inkl. Tests, Storybook-Dokumentation, Accessibility-Check) landest du initial bei:

• 60 Komponenten x 2,5 Tage x 850 Euro = 127.500 Euro (Initialaufwand)

Das klingt nach einer klaren Zahl. Das Problem: Sie ist unvollstandig.

Die versteckten TCO-Treiber

1. Maintenance-Tail (der langste Kostentreiber)

Jede Komponente, die du selbst baust, gehorst du. Das bedeutet: Jedes Browser-Update, jedes Framework-Major-Release (React 19, Next.js 15+), jede Accessibility-Standard-Aktualisierung (WCAG 3.0 ist jetzt Pflicht), jede Design-System-Iteration landet in deinem Backlog. Der Maintenance-Aufwand fur eine Component Library mit 60 Komponenten uber 3 Jahre liegt erfahrungsgemas bei 40-60 % des Initialaufwands pro Jahr.

Das sind 50.000-75.000 Euro/Jahr allein fur "die Bibliothek am Laufen halten" - ohne Features, ohne neue Vertikale, ohne Optimierungen.

2. Opportunity Cost - das unsichtbarste Argument

Die drei bis vier Senior-Frontend-Entwickler, die an deiner Component Library arbeiten, arbeiten nicht an Features, die Umsatz generieren. Bei einem durchschnittlichen SaaS- oder E-Commerce-Team mit 8-12 Frontend-Engineers bindet eine selbst gepflegte Library typischerweise 25-35 % der Engineering-Kapazitat dauerhaft.

Das ist keine Zahl, die in Budgetplanen auftaucht. Aber sie ist real - und sie ist der Hauptgrund, warum Teams, die ihren Custom-Build ehrlich evaluieren, zur Buy-Entscheidung kommen.

3. Performance Debt

Komponenten, die du vor 18 Monaten gebaut hast, entsprechen nicht mehr dem Stand der Technik fur Core Web Vitals (LCP, INP, CLS). Inkrementelle Performance-Optimierung uber eine grosse Custom-Library ist ein kontinuierlicher Aufwand, der bei production-ready Component Sets vom Anbieter ubernommen wird.

4. Onboarding-Friction fur neue Entwickler

Eine undokumentierte, gewachsene Custom-Library hat einen Einarbeitungsaufwand von typischerweise 4-6 Wochen bis zur produktiven Selbstandigkeit. Eine strukturierte, dokumentierte Component Library mit klarer API reduziert das auf 1-2 Wochen. Bei 2-3 Neueinstellungen pro Jahr sind das 12-18 produktive Entwickler-Wochen, die verloren gehen.

Wann Custom Build gewinnt

Build ist die richtige Entscheidung, wenn mindestens zwei der folgenden Faktoren zutreffen:

Hochdifferenziertes UX als Kernkompetenz: Wenn dein Produkterlebnis der Hauptdifferenziator im Markt ist - denk an Konfiguratoren, interaktive Visualisierungen, branchenspezifische Checkout-Flows - und wenn du das intern als Wettbewerbsvorteil verteidigen willst, ist Custom Build die richtige Grundlage.

Sehr spezifische technische Anforderungen: Wenn du sehr ungewohnliche Backend-Datenstrukturen, proprietare Design-Systeme mit 200+ Tokens oder regulatorische Anforderungen (z.B. komplexe DSGVO-Consent-Flows, Medizin/Pharma-spezifische UX) hast, die kein production-ready Kit abdeckt.

Langfristige In-house-Engineering-Investition: Wenn du planst, dein Frontend-Team auf 15+ Engineers zu skalieren und Frontend-Engineering als strategische Kernkompetenz aufzubauen, ist der Build-Pfad langfristig oft okonomischer.

Genugen Startkapital und Zeit: Wenn ein Launch-Termin in 90 Tagen kein K.O.-Kriterium ist und du 12-18 Monate fur einen sauberen In-house-Build einplanen kannst.

Wann Growth Kits gewinnen

Buy (bzw. production-ready Kits) gewinnen, wenn diese Faktoren dominieren:

Time-to-Market als harter Constraint: Wenn der Launch in 60-90 Tagen sein muss und du mit einem soliden, GEO-ready, performance-optimierten Storefront starten willst, sind fertige Kits der einzige Pfad. Custom Builds in dieser Zeitspanne bedeuten immer: initiale technische Schulden, unfertige Accessibility, Performance-Gaps.

Engineering-Kapazitat ist das Bottleneck: Wenn dein Team 6 Frontend-Engineers hat und davon zwei permanent in der Component Library stecken, fehlst du ihnen anderswo. Production-ready Kits befreien Kapazitat fur umsatzrelevante Features.

Multi-Vertical-Expansion: Wenn du in den nachsten 12 Monaten mehr als ein neues Vertikal launchen willst (B2C + SaaS, oder Marketplace + B2B), ist ein Custom-Build pro Vertikal wirtschaftlich nicht skalierbar. Kits, die uber Vertikale hinweg konsistent sind, ermoglichen das.

Performance und Compliance als Plattform-Eigenschaft: Wenn Core Web Vitals, WCAG 3.0 und Schema.org-GEO-Readiness Pflicht sind und kein dedicated Performance-Engineer im Team sitzt, tragt das das Kit.

Der Laioutr-Datenpunkt ist hier relevant: Teams, die auf production-ready Growth Kits wechseln, berichten von -65 % Time-to-Launch im Median vs. klassischem In-house-Aufbau (Q1/Q2 2026 Felddaten). LCP-Median von 1,2 Sekunden ist eine Plattform-Eigenschaft, keine Sprint-Aufgabe.

Das Entscheidungsraster

Die ehrliche Rechnung: 5-Jahres-TCO

Eine vollstandige TCO-Analyse fur das Komponenten-Thema findest du in unserem Artikel zum 5-Jahres-TCO eines Composable Frontends. Hier die Kurzfassung fur den Komponenten-spezifischen Vergleich:

Custom Build (60 Komponenten, 8-Engineer-Team, 3 Vertikale in 5 Jahren):

• Initiale Entwicklung: 130.000 EUR
• Maintenance Jahr 1-5: 65.000 EUR/Jahr = 325.000 EUR
• Onboarding-Friction (3 neue Devs/Jahr, 5 Wochen): 75.000 EUR
• Performance-Rework (2 Major-Cycles): 40.000 EUR
• Gesamt 5 Jahre: ca. 570.000 EUR (ohne Opportunity Cost)

Growth Kit (Laioutr-Abo, 3 Vertikale):

• Plattform-Abo 5 Jahre: variiert nach Team-Grosse (auf Anfrage)
• Customization-Aufwand initial: 30.000-50.000 EUR
• Maintenance: im Abo enthalten
• Gesamt 5 Jahre: signifikant niedriger, abhangig vom Abo-Tier

Der Break-Even liegt bei den meisten Team-Gro-en und Launch-Frequenzen klar auf der Kit-Seite - das haben Teams bestellt, die diesen Vergleich sauber gemacht haben.

Die drei Fragen, die du intern klaren musst

Bevor du die Entscheidung triffst, beantworte diese drei Fragen ehrlich:

1. Ist unsere UX-Differenzierung so spezifisch, dass kein vorhandenes Kit sie abdecken kann?

Schau dir die Laioutr B2C Growth Kits und das Growth Kit-Katalog-Overview an, bevor du mit "Nein" antwortest. Viele Teams, die glauben, sie haben spezifische Anforderungen, finden 80 % ihrer Anforderungen in vorhandenen Kits - und konnen die verbleibenden 20 % customizen.

2. Wie viel Engineering-Kapazitat wollen wir dauerhaft in Library-Maintenance binden?

Rechne den Maintenance-Tail ehrlich durch: nicht als Einmalschatzung, sondern als laufende Budget-Line fur 5 Jahre.

3. Was ist unser realistischer Time-to-Launch fur das nachste Vertikal?

Wenn die Antwort "6-12 Monate" ist und du gleichzeitig Wachstumsziele fur das nachste Quartal hast, ist das ein klares Signal.

Wie die Entscheidung in der Praxis lauft

Die meisten Teams, die zu uns kommen, haben eine Mischsituation: ein bestehendes Custom-Component-Set (meist 2-4 Jahre alt, wachsende Tech-Schulden) und einen neuen Launch, der schnell gehen muss. Die pragmatische Losung ist oft ein hybrider Ansatz:

• Bestehendes Legacy-Set lauft weiter fur etablierte Flachen
• Neues Vertikal oder neue Flache (Redesign, neue Marke, neues Marktland) startet auf Growth-Kit-Basis
• Uber 12-24 Monate Migration des Legacy-Sets auf Kit-Basis, Schritt fur Schritt

Das gibt dir den Time-to-Market-Vorteil fur das Neue, ohne das Bestehende sofort wegzuwerfen.

Wenn du diese Entscheidung fur dein Team strukturiert durchrechnen willst, zeigen wir dir das im Demo-Gesprach konkret: Laioutr Demo anfragen.

Weitere Themen aus der Laioutr-Plattform

• Laioutr Platform - die Frontend Management Platform fur Composable Storefronts
• Agentic Frontend Management Platform - der Frontend-Layer als eigenstaendige, steuerbare Schicht
• Growth Kit-Katalog: UI-Sets fur 8 Branchen - alle verfugbaren Growth Kit-Vertikale im Uberblick
• B2C Growth Kit - das production-ready Component Set fur B2C-E-Commerce
• 5-Jahres-TCO eines Composable Frontends - die vollstandige TCO-Analyse

Uber den Autor: Marcel Thiesies ist Co-Founder und CEO von Laioutr. Er hat die Kategorie Frontend Management Platform mitgepraegt und begleitet Enterprise- und Scale-up-Teams beim Build-vs-Buy-Entscheidungsprozess fur ihre Frontend-Architektur.