Discovery & Architektur
Extraktion der Konfiguratorregeln aus der Engineering-Dokumentation, SAP-Integrationstopologie, Händlerstufen- und regionales Preismodell, DSGVO-Datenfluss-Kartierung, EU-Residenz-Design.
Fallstudie · Fertigung · E-Commerce
Wie wir ein maßgeschneidertes Next.js-Händlerportal und einen Produktkonfigurator für REHAU — den bekannten weltweiten Hersteller von Polymerprodukten — gebaut haben, mit Konfigurationsregeln auf Engineering-Niveau, regionsbewusster Preisgestaltung, Echtzeit-SAP-gesteuerten Beständen und einem Händler-Back-Office, dem die Zentrale vertraut. Live über mehrere europäische Märkte hinweg mit EU-Datenresidenz, konzipiert für die Compliance-Latte der USA und EU.
Das Händlernetzwerk von REHAU war seinem alten Bestellportal entwachsen. Kataloge lagen in Tabellenkalkulationen, Preise variierten stillschweigend nach Region, und Händler in Deutschland, den Niederlanden, Frankreich, Schweden und Polen verbrachten Stunden damit, Profilsystem-Bestellungen von Hand zu konfigurieren — und sie dann vor der Übermittlung gegen das Engineering-Regelwerk der Zentrale doppelt zu prüfen. Der Kunde wollte eine einzige Webplattform mit einem geführten Konfigurator, regionsbewusster Preisgestaltung, Echtzeit-SAP-gesteuerten Beständen und einer Back-Office-Oberfläche, der die Zentrale für die Compliance-Latte eines börsennotierten Herstellers wirklich vertrauen konnte. Fertige B2B-Commerce-Suiten — SAP Commerce Cloud und Adobe Commerce B2B — konnten einen Katalog und Händlerkonten liefern, doch keine konnte die Konfiguratorregeln auf Engineering-Niveau, die die Profilsystem-Produktlinie von REHAU erfordert, ohne einen erheblichen Fork der Konfigurator-Engine des Anbieters hosten. Wir haben das Portal von Grund auf auf einem maßgeschneiderten Next.js- + NestJS-Stack gebaut, mit einer streamenden SAP-ERP-Integration und einem Händler-Back-Office, das für die Zentrale, Händler und Prüfer in der gesamten EU konzipiert ist — und an denselben Kontrollen ausgerichtet, die ein US-Deployment erfordern würde.
Ein Überblick darüber, was die REHAU-B2B-Commerce-Entwicklung über das Händlerportal und das Back-Office der Zentrale geliefert hat.

Die mit Abstand größte Architekturfrage in diesem Projekt war, ob eine fertige B2B-Commerce-Suite — SAP Commerce Cloud (ehemals Hybris) oder Adobe Commerce B2B (Magento) — erweitert oder ein maßgeschneidertes Next.js-Portal durchgängig gebaut werden sollte. Beide Anbieterplattformen handhaben Katalog, Händlerkonten und gestaffelte Preise gut; keine hostet einen Konfigurator auf Engineering-Niveau mit dimensionalen und kombinatorischen Regeln ohne einen erheblichen Fork der Konfigurator-Engine des Anbieters. Für die Profilsystem-Produktlinie von REHAU IST der Konfigurator das Produkt: Händler in den USA und der EU brauchen ein Werkzeug, das Profil-und-Zubehör-Kombinationen gegen dasselbe Engineering-Regelwerk validiert, das die Zentrale verwendet, und dann eine deterministische SKU-Liste, ein druckbares Spezifikationsblatt und ein Preisangebot ausgibt, das das SAP-ERP Zeile für Zeile in Rechnung stellt. Das auf einem Anbieter-Konfigurator zu bauen, bedeutet, für immer einen Fork der Anbieter-Laufzeit zu besitzen, wobei jedes SAP-Commerce-Cloud-Release erneut Migrationskosten verursacht.
Eine maßgeschneiderte Entwicklung im Rahmen der individuellen Softwareentwicklung auf Next.js + NestJS gibt dem Team die volle Eigentümerschaft über die Regel-Engine, die SAP-Integrationstopologie und die UX des Händler-Back-Office, ohne Lizenzierung pro Nutzer und ohne vom Anbieter vorgegebene Release-Kadenz. Die Abwägung ist eine höhere anfängliche Entwicklung — doch für einen Hersteller, der ein marktübergreifendes Händlerprogramm betreibt, zahlen schon die Einsparungen bei den Lizenzen pro Nutzer die maßgeschneiderte Entwicklung innerhalb des ersten Rollout-Zyklus, und die Fähigkeit, Konfiguratorregel-Änderungen am selben Tag auszuliefern, an dem das Engineering sie freigibt, ist ein struktureller Vorteil, den kein SaaS-Anbieter erreicht.
| Dimension | Maßgeschneidertes Next.js (REHAU) | SAP Commerce Cloud | Adobe Commerce B2B |
|---|---|---|---|
| Konfigurator mit Engineering-Regeln | Vollständig maßgeschneiderte Regel-Engine — Maße, Profilkombinationen, Zubehörkompatibilität | Anbieter-Konfigurator — Fork für nicht standardmäßige Regeln erforderlich | Eingeschränktes Konfigurierbare-Produkte-Modell — Fork erforderlich |
| Deterministische SKU- & Angebotsausgabe | Angebot stimmt per Design Zeile für Zeile mit ERP-Rechnung überein | Native SAP-Ausrichtung; durch Anbieter-SKU-Modell beschränkt | Erfordert maßgeschneiderte Middleware für SAP-konforme SKUs |
| Aktualität der SAP-Integration | Streaming über Event-Bus — unter einer Minute | Stark nativ — eigenes Ökosystem | Konnektorabhängig — variiert je nach Integrator |
| Storefront-Performance | Next.js ISR + CDN-Edge — TTFB unter einer Sekunde | Schwere Laufzeit; durch Spartacus headless gemildert | PWA Studio möglich; benötigt Tuning |
| Lizenzierung pro Nutzer | Keine — eigener Quellcode | Lizenzierung pro CCU und pro Umgebung | Gestaffelte Commerce-Lizenz + B2B-Modul |
| Release-Kadenz | Am selben Tag nach Engineering-Freigabe | Vom Anbieter vorgegeben; Upgrades disruptiv | Vierteljährliche Plattform-Releases |
| Langfristige Eigentümerkosten | Höher anfänglich; null Lizenzierung oder Lock-in | Niedriger anfänglich; hohe laufende Lizenz- + Upgrade-Kosten | Mittel anfänglich; laufende Lizenz- + B2B-Modul-Kosten |
Quellen: Next.js-Dokumentation, SAP-Commerce-Cloud-Hilfeportal, Adobe-Commerce-B2B-Dokumentation.

Regionseinstellungen steuern Währung, Steuer, Lieferzeiten und händlerstufenbasierte Rabatte über jeden Markt, den das Portal bedient — Deutschland, die Niederlande, Frankreich, Schweden, Polen und weitere EU-Rollouts. Ein Händler in München sieht Europreise abzüglich der deutschen Mehrwertsteuer und die Lieferzeiten, die sein zugewiesenes Lager tatsächlich einhalten kann; ein Händler in Stockholm sieht schwedische Kronen, schwedische Mehrwertsteuer und Lieferzeiten, die spezifisch für die skandinavischen Distributionszentren sind. Händlerstufenbasierte Rabatte kommen zusätzlich zu den regionalen Listenpreisen hinzu, sodass dieselbe SKU drei verschiedenen Händlern drei verschiedene Preise zeigen kann — und das Händler-Back-Office in der Zentrale kann genau sehen, welche Stufe und welcher Override jede Endzahl erzeugt hat.
Die Bestandseinsicht zieht live aus dem SAP ERP über eine streamende Integration: Bestands- und Preisänderungsereignisse fließen aus SAP über einen Event-Bus in die eigenen PostgreSQL- und Redis-Caches des Portals, mit durchgängiger Aktualität unter einer Minute. Der Händler-Storefront fragt SAP nie synchron ab — er liest aus seinen eigenen Caches —, doch jede Seite spiegelt die ERP-Wahrheit innerhalb einer Minute wider. Händler sehen realistische Liefertermine, bevor sie sich auf eine Bestellung festlegen, einschließlich Rückstandssignalen und Hinweisen auf Ersatzprodukte, wenn ein Artikel knapp ist. Die Bestellübermittlung geht über eine ausgehende Warteschlange mit Idempotenzschlüsseln zurück an SAP, plus ein Abgleich-Job, der verpasste Ereignisse innerhalb der Stunde abfängt, sodass keine Händlerbestellung je zweimal in SAP landet und keine Portalbestellung je SAP überhaupt nicht erreicht.

Das Back-Office ist die Oberfläche, von der aus die Zentrale das Händlerprogramm steuert. Eine einheitliche Bestell-Pipeline zeigt jede laufende Bestellung über jeden Händler und jede Region hinweg — übermittelt, validiert, an SAP gesendet, erfüllt, versandt. Ausnahmewarteschlangen bringen festsitzende Lieferungen, fehlgeschlagene Bonitätsprüfungen und genehmigungsbedürftige Preis-Overrides zum Vorschein, sodass ein Operations-Manager, der an einem MEZ-Arbeitstag mit Überlappung mit der US-Ostküste (9–13 Uhr ET) arbeitet, die Warteschlange einmal abarbeiten und darauf vertrauen kann, dass nichts durchgerutscht ist. Händler-Health-Metriken — Bestellvolumentrends, Rückgabequoten, durchschnittliche Konfigurator-bis-Bestellung-Zeit — ermöglichen es dem Dealer-Success-Team, Konten zu markieren, die Aufmerksamkeit brauchen, bevor der Händler abwandert oder beginnt, außerhalb des Portals zu bestellen.
Die Suche über den Katalog läuft auf Elasticsearch mit pro Sprache abgestimmten Synonymen, sodass ein Händler, der ein Produkt nach seinem Handelsnamen, seinem deutschen umgangssprachlichen Namen oder seiner SKU sucht, auf derselben Ergebnismenge landet. Der Katalog selbst ist CMS-gesteuert: Marketingteams aktualisieren Produkttexte, Hero-Bilder und saisonale Kampagneninhalte über eine Content-Management-Oberfläche ohne Engineering-Beteiligung, während Layout-Primitive das Markensystem fixieren, sodass eine Marketing-Änderung niemals eine Konfiguratorseite zerstören kann. Das Ergebnis ist ein Back-Office, das zum bestehenden Betriebsrhythmus der Zentrale passt — Bestell-Pipeline, Händler-Health, Inhaltsaktualisierungen — statt den Betrieb in eine vom Anbieter vorgegebene UX zu zwingen.
Das REHAU-Portal ist eine Next.js- + NestJS-Anwendung, die auf Kubernetes innerhalb der EU läuft und über eine streamende Event-Topologie mit SAP integriert ist — konzipiert für dieselben Kontrollen, die ein US-und-EU-Deployment derselben Plattform erfordern würde.
Die Anwendungsschicht läuft als Next.js-Storefront (App Router, ISR für Katalog- und Inhaltsseiten), gestützt durch ein NestJS-API-Gateway. Katalog-Lesevorgänge treffen zuerst den Next.js-ISR-Cache, dann Redis, dann PostgreSQL — der Storefront blockiert nie auf SAP. Der Konfigurator läuft serverseitig: Die Regel-Engine, der SKU-Resolver und der Preisrechner liegen alle im NestJS-Service, wobei die Konfigurator-UI auf dem Next.js-Client Teilzustände postet und validierte Regelergebnisse zurückerhält. Die Suche läuft auf Elasticsearch mit sprachspezifischen Analyzern und einem pro Markt gepflegten Synonymwörterbuch. Das CDN ist CloudFront mit EU-Edge-Standorten, das sowohl statische Assets als auch ISR-gerendertes HTML bedient.
Die SAP-Integration ist beim Lesen streng asynchron und einseitig. Bestände, Preise und Stammdaten fließen aus SAP über einen Event-Bus — Kafka in der Produktionstopologie — in PostgreSQL und Redis auf der Portalseite, mit idempotenten Consumern und einem stündlichen Abgleich-Job, der den kanonischen Zustand jedes Datensatzes, dessen Event-Stream unvollständig aussieht, erneut abruft. Die Bestellübermittlung geht über eine ausgehende Warteschlange mit Idempotenzschlüsseln zurück an SAP, sodass ein Wiederholungsversuch nie eine doppelte Bestellung im ERP erzeugt und ein vorübergehender SAP-Ausfall nie die Bestellung eines Händlers verliert — sie liegt in der ausgehenden Warteschlange, bis SAP zurückkommt. Die ERP-Grenze ist hart: Das Portal fragt SAP nie aus einer Nutzeranfrage ab, und SAP fragt das Portal überhaupt nicht ab. Diese Architektur ist es, die die Streaming-vs.-Batch-Abwägung zugunsten des Händlers funktionieren lässt — er sieht frische Daten ohne die Latenz eines synchronen ERP-Aufrufs.
Die EU-Datenresidenz wird auf der Infrastrukturebene durchgesetzt: PostgreSQL-Primary in AWS Frankfurt mit einer Lese-Replik in Dublin, Redis in derselben Region, Elasticsearch in derselben Region und CloudFront-Edge auf EU-Edge-Standorte beschränkt für jeden Cache, der händleridentifizierende Daten hält. SAP selbst verbleibt im bestehenden Rechenzentrum des Herstellers; der Event-Bus endet innerhalb der EU, bevor ein Nicht-EU-Spiegel berührt wird. Audit-Logs erfassen jede Preisänderung, jeden Override, jede Genehmigung — und erfüllen die Compliance-Latte eines börsennotierten Herstellers und die Dokumentationslatte, die ein künftiges SOC-2-Audit prüfen wird. Die Infrastruktur wird über Terraform verwaltet, mit Grafana-Dashboards für die Systemgesundheit und Sentry für die Fehlerverfolgung auf Anwendungsebene. Die Compliance-Aufstellung unterstützt sowohl DSGVO-Pflichten in der Europäischen Union als auch den US-Bundesstaaten-Datenschutz-Stack — CCPA / CPRA (Kalifornien), VCDPA (Virginia), CPA (Colorado), CTDPA (Connecticut), UCPA (Utah), TDPSA (Texas) und Oregon CPA —, falls ein künftiger US-Rollout dies erfordert.
Compliance-Aufstellung: DSGVO-konform · ISO-27001-bereit · SOC 2 Type II in Vorbereitung · HIPAA-fähig · CCPA-berücksichtigt.
Eine fünfphasige Entwicklung, die das REHAU-Händlerportal von der Produktspezifikation bis zur Produktion über sechs europäische Märkte führte.
Extraktion der Konfiguratorregeln aus der Engineering-Dokumentation, SAP-Integrationstopologie, Händlerstufen- und regionales Preismodell, DSGVO-Datenfluss-Kartierung, EU-Residenz-Design.
Next.js-Storefront, NestJS-API-Gateway, PostgreSQL- + Redis-Caches, Händler-Authentifizierung und -Kontomodell, Basiskatalog, Regions- und Stufenpreis-Engine.
Regel-Engine für die Profilsystem-Konfiguration, deterministische SKU- und Angebotsausgabe, streamende SAP-Integration über Event-Bus, ausgehende Bestellwarteschlange mit Idempotenz, Abgleich-Job.
Back-Office der Zentrale für Bestell-Pipeline und Ausnahmewarteschlangen, Händler-Health-Metriken, Audit-Logs pro Aktion, Berechtigungsmodell für Zentrale-/Regional-/Händler-Rollen, CMS für Kataloge und Kampagnen.
Gestaffelter Rollout über Deutschland, die Niederlande, Frankreich, Schweden und Polen; mehrsprachige QA; sprachspezifische Elasticsearch-Synonym-Abstimmung; Grafana-Dashboards; Bereitschaftsrotation, abgestimmt auf MEZ + Überlappung mit der US-Ostküste.
Der Konfigurator ist der Teil der Entwicklung, der die Make-vs.-Buy-Frage entschieden hat. Die Profilsysteme von REHAU tragen dimensionale Beschränkungen (minimale und maximale Rahmenbreiten und -höhen), Profilkombinationsregeln (welche Profile mit welchen zusammenpassen können), Zubehörkompatibilität (welche Dichtungen, Verstärkungen und Verbinder eine bestimmte Profilkombination erfordert) und regionale Zertifizierungsregeln (eine für Deutschland gültige Konfiguration ist aufgrund von Wärmeleistungsanforderungen möglicherweise nicht für Schweden gültig). All dies liegt in einer Regel-Engine im NestJS-Service, deklarativ ausgedrückt, sodass ein Ingenieur, der eine Regeländerung freigibt, die Regel selbst statt einer prozeduralen Implementierung lesen kann. Die Konfigurator-UI postet Teilzustände — die laufende Auswahl eines Händlers — und erhält einen validierten Zustand mit den nächsten zulässigen Optionen für jede verbleibende Eingabe zurück, sodass einem Händler nie eine Kombination angeboten wird, die das Engineering-Regelwerk ablehnen würde. Wenn der Händler eine Konfiguration abschließt, gibt die Regel-Engine eine deterministische SKU-Liste (dieselbe Eingabe erzeugt immer denselben SKU-Satz), ein druckbares Spezifikationsblatt und ein Preisangebot aus, das Zeile für Zeile auf das abgebildet wird, was SAP in Rechnung stellt. Die Portal-zu-ERP-Ausrichtung ist es, die das Vertrauen der Händler ermöglicht hat: Der Preis, den sie sehen, ist der Preis, den sie zahlen, und das Angebots-PDF, das sie ihrem Endkunden aushändigen, ist in beide Richtungen verbindlich.
Das REHAU-Händlerportal startete über sechs europäische Märkte — Deutschland, die Niederlande, Frankreich, Schweden, Polen und einen weiteren EU-Markt im gestaffelten Rollout — mit einer mehrsprachigen Benutzeroberfläche, regionsbewusster Preisgestaltung und EU-Datenresidenz auf der Anwendungs- und Suchschicht. Die Plattform wurde von Tag eins an für die Compliance-Latte der USA und EU konzipiert: Obwohl die anfänglichen Märkte alle europäisch sind, sind die Datenverarbeitungsarchitektur, die Audit-Log-Abdeckung und das Rollen-Berechtigungsmodell an denselben Kontrollen ausgerichtet, die ein US-Händlernetzwerk-Deployment erfordern würde. Datenschutzpflichten sind für europäische Nutzer an der DSGVO und am US-Bundesstaaten-Datenschutz-Stack ausgerichtet — CCPA / CPRA (Kalifornien), VCDPA (Virginia), CPA (Colorado), CTDPA (Connecticut), UCPA (Utah), TDPSA (Texas) und Oregon CPA —, falls ein US-Rollout folgt.
In der Praxis bedeutet das, dass händleridentifizierende Daten und Endkunden-Bestelldaten auf jeder Schicht innerhalb der EU bleiben: PostgreSQL-Primary in AWS Frankfurt mit einer Lese-Replik in Dublin, Redis und Elasticsearch in derselben Region und CloudFront-Edge auf EU-Edges beschränkt für jeden Cache, der personenbezogene Daten hält. Die EU-Datenresidenz für einen weltweiten Hersteller mit Hauptsitz in Deutschland ist eine regulatorische Notwendigkeit, keine Marketingzeile — und die Art, wie die SAP-Integration strukturiert ist, bedeutet, dass ein künftiger US-Rollout in einer US-AWS-Region hochgefahren werden kann, ohne die ERP-Grenze neu zu architektieren. Die Plattform ist für US- und EU-Märkte auf derselben Codebasis entwickelt, mit regionaler Infrastruktur-Bindung statt regionaler Forks der Anwendung.
Die aktive Roadmap für die REHAU-Plattform umfasst eine Partner-API für Monteur-Integrationen (sodass Mess- und CAD-Werkzeuge von Drittanbietern Konfigurationen im Namen eines Händlers übermitteln können), eine AR-gesteuerte Konfigurator-Vorschau für Wohn-Profilsysteme auf dem Mobilgerät, tiefere SAP-Automatisierung rund um die Lieferzeitplanung (prädiktive Lieferzeiten basierend auf der Produktionslinienauslastung statt statischer Lagerregeln) und weitere EU-Markt-Rollouts. Die Architektur unterstützt einen US-Rollout ohne Re-Plattformierung — derselbe Next.js-Storefront, dieselbe Regel-Engine, dieselbe SAP-Integrationstopologie — und unser Cloud-&-DevOps-Team hat die Terraform-Module bereit, um eine US-Region hochzufahren, wenn das Programm es verlangt.
Wenn Sie ein B2B-Commerce-Portal, eine Händlernetzwerk-Plattform mit einem Produktkonfigurator oder eine ERP-integrierte Commerce-Oberfläche für Zielgruppen in den USA und der EU planen, haben wir diesen Stack für einen weltweiten Hersteller durchgängig ausgeliefert und können den Entwicklungszeitplan deutlich verkürzen. Das Engineering-Team hinter dieser Entwicklung sitzt innerhalb der YuSMP Group. Wir arbeiten auf Time-&-Materials-Basis für sich entwickelnde Programme und mit dedizierten Entwicklerteams für die laufende Lieferung, mit einem MEZ-Arbeitstag und einem garantierten Überlappungsfenster mit der US-Ostküste (9–13 Uhr ET) für Stand-ups, Demos und Incident-Response.
Ein B2B-Commerce-MVP mit Katalog, Händlerkonten, regionsbewusster Preisgestaltung, einem grundlegenden Bestellworkflow und einer einzelnen ERP-Integration kostet in der Regel 200.000 bis 500.000 US-Dollar. Ergänzt man einen geführten Produktkonfigurator mit Engineering-Regel-Validierung, Echtzeit-Bestandseinsicht, händlerstufenbasierten Rabatten und einem Back-Office für die Zentrale, bringt das eine vollständige Plattform auf 500.000 bis 1,2 Mio. US-Dollar. Die wesentlichen Kostentreiber sind die Regel-Engine des Konfigurators, die Aktualitäts- und Abgleichlogik der ERP-Integration und die für Audit und Ausnahmebehandlung erforderliche Händler-Back-Office-Oberfläche.
SAP Commerce Cloud und Adobe Commerce B2B sind hervorragend für kataloggeführten Commerce mit unkomplizierten konfigurierbaren Produkten, doch sie beschränken den Konfigurator auf ihre eigene Regel-Engine und ihr eigenes Komponentenmodell. Hersteller mit Engineering-Produktregeln — Profilsystem-Kombinationen, dimensionale Beschränkungen, Zubehörkompatibilität — enden in der Regel damit, den Konfigurator des Anbieters umfangreich zu forken. Eine maßgeschneiderte Next.js- + NestJS-Entwicklung gibt dem Team die volle Kontrolle über die Regel-Engine, die SAP-Integrationstopologie und die UX des Händler-Back-Office, ohne Lizenzierung pro Nutzer und ohne vom Anbieter vorgegebene Release-Kadenz.
Eine produktionsreife SAP-Integration nutzt ein Streaming-Muster: Bestände, Preise und Stammdaten fließen von SAP über einen Event-Bus (Kafka, RabbitMQ oder SAP Event Mesh) in die eigenen PostgreSQL- und Redis-Caches der Commerce-Plattform. Der Storefront liest mit unter einer Minute Aktualität aus seinen eigenen Caches, niemals synchron aus SAP. Bestellübermittlung und Bonitätsprüfungen gehen über eine ausgehende Warteschlange mit Idempotenzschlüsseln zurück an SAP, plus ein Abgleich-Job, der verpasste Ereignisse innerhalb der Stunde abfängt.
EU-Datenresidenz für eine B2B-Commerce-Plattform bedeutet, dass die primäre Datenbank, der Suchindex, die Cache-Schicht und die CDN-Edge-Caches, die Händler- oder Endkunden-Personendaten halten, alle innerhalb der EU liegen müssen. Für REHAU und ähnliche in Deutschland ansässige Hersteller bedeutet das in der Regel AWS Frankfurt oder Dublin für die Anwendungsschicht, wobei das SAP-ERP selbst im bestehenden Rechenzentrum des Herstellers verbleibt. Die grenzüberschreitende SAP-Integration nutzt verschlüsseltes Streaming mit EU-seitiger Datenminimierung, bevor ein Nicht-EU-Spiegel berührt wird.
Ein fokussiertes MVP — Katalog, Händlerkonten, regionsbewusste Preisgestaltung, eine ERP-Integration und ein grundlegender Konfigurator — dauert in der Regel 24 bis 32 Wochen. Engineering-Regel-Validierung, deterministische SKU-Generierung, druckbare Spezifikationsblätter und händlerstufenbasierte Preisgestaltung kommen mit 8 bis 12 Wochen hinzu. Ein vollständiges Back-Office für die Zentrale mit Bestell-Pipeline, Ausnahmewarteschlangen, Händler-Health-Metriken und Audit-Logs pro Aktion fügt weitere 8 bis 10 Wochen hinzu. Mehrsprachige Benutzeroberfläche für europäische Märkte und sprachspezifische Suchsynonyme kommen mit 4 bis 6 Wochen obendrauf.
Verwandte Leistungen

Produktionsreife SaaS-Lösungen, B2B-Portale und Händlerplattformen, gebaut auf TypeScript, React, Next.js, NestJS und Node.js für US- & EU-Teams.
Webanwendungsentwicklung entdecken →
Durchgängiges Product Engineering für ambitionierte US- & EU-Unternehmen, gebaut von Senior-Teams nach DSGVO-konformen und SOC-2-orientierten Praktiken.
Individuelle Softwareentwicklung entdecken →
AWS-, Azure- und GCP-Migrationen, Kubernetes-Plattformen, CI/CD und Observability für US- & EU-Teams.
Cloud & DevOps entdecken →Verwandte Fallstudien
PropTech-Marktplatz + Admin für Wohnbauträger — Bestandsraster auf Wohnungsebene, Multi-Rollen-Workflows, US- + EU-Datenresidenz.
Fallstudie ansehen → FinTech · AutoHändler-Webplattform mit Bitrix24-CRM-Sync, Dadata-Vorbefüllung und Echtzeit-Sprachbenachrichtigungen — ein einziger Eingangskanal für jede Auto-Finanzierungsanfrage.
Fallstudie ansehen → Verbraucherdatenschutz · VPNNatives iOS- + Android-VPN mit WireGuard, No-Logs-Backend, Split-Tunnel und App-Store- + Google-Play-Launch für USA & EU.
Fallstudie ansehen →