Tech-Deep-Dive · Webshop
Headless Commerce.
B2B-Konfigurator. ERP-Adapter. Eigene Daten.
Custom-Shopfronts ohne Plattform-Lock. Card- und SEPA-Payment
parallel, Schema-driven B2B-Konfigurator mit
INP < 100 ms
auf der Form, ERP-Anbindung via Adapter-Pattern, eigene
Postgres als Single-Source-of-Truth. Live-Reference:
akademie.unitedsynergy.com.
Capability-Stack
Acht Schichten, was sie können.
Konkrete Tool-Wahl behalte ich für mich, wer kopiert, kopiert die falsche Schicht. Was zählt sind die Eigenschaften: kleine Bundles, harter Payment-Layer, ERP-Pattern statt ERP-Plugin.
Frontend
Compile-First, Form-Action-nativ
Bundle < 80 kB JS pro Page · selektives Hydrate DB-Layer
Type-safe + JSONB für Konfigurator-Schemas
Schema → Query → Response, ein Typecheck Payment
Card international + SEPA national
Idempotente Webhooks · Card-Migration ohne Re-Auth Search
Eigene Search ohne SaaS-Lock
DB-FTS oder Self-hosted Search-Engine Image-Pipeline
WebP + AVIF + JPEG Auto-Variants
CDN-tauglich, Object-Storage-fähig ERP-Adapter
Pattern statt Plugin
Pro ERP eine Implementierung, Mail-Bridge als POC Auth
Magic-Link + B2B-Account-Mgmt
Wiederkehrende Bestellungen, Saved-Configs Deploy
Container-Cluster, Auto-TLS, Zero-Downtime
CI < 2 min · Rolling-Update via Health-Checks FAQ
Tech-Fragen.
Warum Headless statt Standard-Plattform?
Eigene Datenhoheit (Produkt-Katalog, Bestand, Kunden in eigener DB), kein Plattform-Lock-In, keine Transaction-Fees auf den Plattform-Layer. Custom-UX die exakt zum Brand passt, kein Theme-Tweaking. Performance: Bundle-Size unter 80 kB JS pro Page, Lighthouse 95+ als Build-Gate, LCP < 2.0s auf Produkt-Pages. Live-Reference: akademie.unitedsynergy.com.
Card- oder SEPA-Payment?
Beides parallel. Card-Provider international (Stripe), SEPA-Lastschrift + Sofortüberweisung + iDEAL via DACH-Provider (Mollie). Klarna optional. Subscription-Logik über Provider-Billing oder eigene scheduled Jobs auf der DB. Webhooks landen in events-Tabelle, idempotent via Provider-Event-ID-Dedup.
B2B-Konfigurator?
Pro Produkt JSON-Schema mit Optionen (Farbe, Größe, Zubehör, Staffel-Mengen). Frontend rendert Multi-Step-Form aus dem Schema, Backend validiert serverseitig, berechnet Preis aus Options-Permutation und Staffel-Tabelle. Saved-Configurations pro Kundenkonto, Bulk-Order via Excel-Upload, Angebots-Modus für >10k EUR-Volumen. INP < 100 ms auf der Konfigurator-Form als Performance-Target.
ERP-Anbindung?
Adapter-Pattern. Order-Service kennt nur ein Interface (createOrder, updateInventory, syncCustomer), konkrete Adapter pro ERP (Intrexx, SAP, Dynamics, DATEV, Lexoffice). Anfangs oft Mail-Briefkasten als Proof-of-Concept (Order-Confirmation + CSV-Anhang an buchhaltung@), dann Migration auf REST/SOAP. Live-Reference: Shop-zu-Intrexx-Bridge in akademie.unitedsynergy.com.
Migration aus Standard-Shop?
Drei Phasen: 1) Datenexport via Admin-API (Products, Customers, Orders, Inventory) → Mapping zu eigenem Schema. 2) URL-Inventur und 301-Redirect-Map für alle Produkt-URLs (kritisch für SEO). 3) Cutover am Wochenende mit Maintenance-Window, Card-Customer-Migration über Provider-Migration-API (Cards bleiben gültig). IndexNow-Push direkt nach Cutover für Tag-1-3-Re-Indexing.
Performance-Targets?
LCP < 2.0 s auf Produkt-Pages, INP < 100 ms auf Konfigurator-Forms, CLS < 0.05. Erreicht durch Server-Rendering mit Cache-Headers, Image-Pipeline mit WebP/AVIF/JPEG-Varianten, selektives Hydrate (form-only, kein SPA-Bloat), Bundle unter 80 kB JS pro Page. Lighthouse 95+ als Build-Gate in CI. Build bricht ab wenn Score sinkt.
Stack-Sparring oder Code-Walkthrough?
30 Min Erstgespräch, kostenlos. Walkthrough an einer Reference-Implementierung. Konfigurator-Pattern, Payment-Setup, ERP-Adapter.
Erstgespräch buchen