Altsystem-Audit & Regelextraktion
Drei Markenseiten-Rechner Zeile für Zeile auditiert, Geschäftsregeln in einen kanonischen Regelsatz extrahiert, Bug-Historie geprüft, DSGVO- + CCPA-Aufstellung kartiert, Multi-Tenant-Datenmodell entworfen.
Fallstudie · Home Improvement · Web
Wie wir eine produktionsreife Plattform zur Fensterangebotserstellung ausgeliefert haben — eine Laravel-Preis-Engine, ein React-Konfigurator, ein CRM, die drei separate Markenseiten betreiben —, die Käufern in Minuten ein präzises, millimetergenaues Angebot und einem Vertriebsteam einen einheitlichen Lead-Posteingang liefert, mit auditbereiter Aufstellung für die USA und die EU.
Der Hersteller Mosokna kam mit drei Markenseiten, drei voneinander unabhängigen Angebotsrechnern und drei verschiedenen Sammlungen angesammelter Preis-Bugs. Dasselbe Standardfenster wurde je nach Markenseite, auf der der Kunde gerade landete, zu drei verschiedenen Preisen angeboten, und das Vertriebsteam hatte keinen einheitlichen Posteingang für Leads aus den drei Storefronts. Der Produktauftrag war eindeutig: jeden Rechner in einer Engine konsolidieren, Käufern in den Vereinigten Staaten und der Europäischen Union ein präzises, millimetergenaues Angebot mit adressbasierter Maßvorbefüllung geben und den Funnel an ein echtes CRM anbinden. Wir haben jeden Altrechner trotz unvollständiger Dokumentation auditiert, eine Laravel-Preis-Engine entworfen, die jede Geschäftsregel an einem Ort hält, einen React-Konfigurator gebaut, der die Engine ansteuert, und daneben ein CRM-Modul aufgesetzt, das das Vertriebsteam täglich nutzt. Eine Multi-Tenant-Architektur bedeutet, dass ein Deploy alle drei Markenseiten mit markenspezifischen Layouts, regionsspezifischen Preisadaptern und einem gemeinsamen Audit-Trail betreibt. Das Live-Produkt ist unter mosokna.ru für das Home-Improvement-Publikum in den USA und der EU erreichbar.
Ein Überblick darüber, was die Mosokna-Konsolidierung über die Preis-Engine, den Konfigurator, das CRM und drei Markenseiten in ihrem ersten Produktionszyklus geliefert hat.

Die Architekturentscheidung dominierte jeden anderen Hebel beim Neuaufbau. Wir entschieden uns für eine Laravel-Multi-Tenant-Engine statt WordPress-Rechner-Plugins und eines fertigen SaaS-Konfigurators, weil die Abwägungen zu einem Hersteller passten, der drei Markenseiten betreibt, die die Produktphysik, aber nicht das Marken-Storytelling teilen. WordPress-Plugins sind schnell eingebunden und genau der Grund, warum Mosokna in Schwierigkeiten war: Jede Markenseite hatte ihre eigene Plugin-Kopie, ihre eigene Bug-Historie, ihre eigenen Preisregel-Anpassungen, die niemand abgleichen konnte. Ein SaaS-Konfigurator löst das Preis-Engine-Problem, tauscht es aber gegen die Beschränkungen der Anbietervorlagen, das Daten-Lock-in beim Anbieter und die Unmöglichkeit, ein Markenlayout ohne iframe-Verrenkungen an die Engine zu binden.
Laravel Multi-Tenant kehrt beide Abwägungen um. Ein Service hält jede Geschäftsregel — Scheibenanzahl, Profilfamilien, Hardware-Zusatzoptionen, regionale Aufschläge —, und markenspezifische Layouts lesen über eine saubere REST-API aus derselben Engine. Die Konfigurator-Zustandsmaschine liegt in Laravel, und das Frontend ist ein schlanker React- + Redux-Toolkit-Client, der genau das rendert, was die Engine zulässt, sodass eine Preisänderung gleichzeitig auf alle drei Markenseiten ausgeliefert wird, ohne seitenspezifischen Code. Eine künftige vierte Markenseite ist eine Konfigurationszeile, kein Engineering-Projekt.
| Dimension | Laravel Multi-Tenant (Mosokna) | WordPress + Plugins | SaaS-Konfigurator |
|---|---|---|---|
| Isolation der Konfigurationslogik | Eine Engine, ein Regelsatz, markenspezifische Adapter | Plugin-Kopie pro Seite — driftet sofort auseinander | Anbieter-eigen — festes Schema |
| Kosten für Preis-Engine-Neuaufbau | Einen Service anfassen, an alle drei Seiten ausliefern | Drei Plugins anfassen, auf Gleichheit hoffen | Anbieter-Ticket — auf Roadmap warten |
| Kopplung des Lead-Formulars an das CRM | Dasselbe Backend — direkter CRM-Schreibvorgang | Formular-Plugin + Bridge-Plugin + Sync-Job | Nur Webhook an externes CRM |
| Regionale Preisanpassung (USA & EU) | Adapter pro Region gegen eine Engine | Plugin pro Region — Schema-Drift | Regionsgebunden oder zusätzliche Anbietergebühr |
| Individuelles Layout pro Marke | Unabhängige React-Schicht pro Marke | Theme-Vorlage pro Marke | Beschränkungen der Anbietervorlage |
| Audit-Trail über Markenseiten hinweg | Ein Audit-Log — auf Engine-Ebene | Drei Logs — manueller Abgleich | Anbieter-Log — eingeschränkter Export |
| Anbieter-/Abhängigkeits-Lock-in | Offenes Framework — portierbar | Plugin-Ökosystem — moderat | Starkes Anbieter-Lock-in |
Quellen: Laravel-Framework-Dokumentation, React-Dokumentation, OpenStreetMap-Nominatim-Geocoding.

Der Konfigurator ist in React gebaut, wobei Redux Toolkit eine Zustandsmaschine ansteuert, die die Laravel-Engine eins zu eins abbildet. Der Käufer gibt eine Adresse ein, ein OpenStreetMap-Nominatim-Geocoding-Schritt löst sie zu einem Gebäude auf, und eine Typologiesuche anhand der Gebäudeserie zeigt die typischen Fenstermaße für diese Einheit an. Jeder Übergang — Adresse aufgelöst, Maße bestätigt, Scheibenanzahl gewählt, Profil ausgewählt, Hardware-Zusatzoptionen ausgewählt — ist ein abgesicherter Zustand in der Maschine, sodass die Engine niemals eine fehlerhafte Konfiguration erhalten kann. Die millimetergenaue Eingabe wird zunächst clientseitig für Reaktionsschnelligkeit validiert, dann serverseitig für die Verbindlichkeit, bevor ein Preis fixiert wird.
Dieselbe Zustandsmaschine steuert jede Markenseite. Markenspezifische React-Themes liefern die Typografie, Farbpalette und Layoutdichte, die jede Marke verlangt, doch der Zustandsgraph und der Engine-Roundtrip sind identisch. Das Ergebnis ist ein Konfigurator, den ein Käufer in den Vereinigten Staaten oder der Europäischen Union in Minuten abschließen kann, mit einem Preis, der verbindlich statt unverbindlich ist, und einem fertigen Warenkorb, der direkt als qualifizierter Lead im CRM landet. Die durchgängige Web-Oberfläche wird im Rahmen unserer Webanwendungsentwicklung geliefert.

Die Preis-Engine ist in Laravel gebaut, mit PHP-Services, die jede Geschäftsregel halten, die sich über zwei Jahrzehnte Fensterfertigung angesammelt hat. Einfach-, Doppel- und Dreifachverglasungskonfigurationen tragen jeweils ihre eigene Physik und Preiskomponenten; Balkontür-Subtypen erben von derselben Engine, ergänzen aber zusätzliche Öffnungsarten, Hardware-Sets und Montageaufschläge. Regionale Adapter ergänzen regionsspezifische Aufschläge, Währung und Arbeitskostenmultiplikatoren, sodass dieselbe Engine dieselbe Konfiguration über Märkte in den USA und der EU hinweg ehrlich bepreist, ohne den Regelsatz zu forken.
Jeder Alt-Bug der drei stillgelegten Rechner wurde gegen die neue Engine geprüft, und ein Paritäts-Harness verglich über 4.000 historische Angebote Zeile für Zeile mit den neuen Preisen. Wo das alte Ergebnis schlicht falsch war, liefert die neue Engine die richtige Antwort; wo das alte Ergebnis ein bewusstes Zugeständnis war, trägt die Engine es mit einem expliziten Geschäftsregel-Kommentar weiter, damit der nächste Entwickler es findet. Die Engine sitzt hinter derselben REST-API, die der Konfigurator nutzt, und das CRM liest direkt aus ihr — keine separate „Preis-Snapshot"-Kopie driftet im Lead-Datensatz. Die Preisschicht wird im Rahmen unserer individuellen Softwareentwicklung geliefert.

Das CRM ist in dieselbe Laravel-Anwendung eingebaut wie die Preis-Engine, sodass ein Lead in dem Moment im Posteingang landet, in dem der Käufer einen Warenkorb abschließt — keine Webhook-Brücken, keine Sync-Jobs, keine eventually-consistent Lücken. Vertriebsmanager sehen Leads nach Markenseite gruppiert, nach Konfigurator-Vollständigkeit und Adressauflösung bewertet und automatisch an das richtige Beratungsteam weitergeleitet. Die Multi-Tenant-Datenisolation läuft auf Datenbankzeilenebene: Jeder Datensatz trägt einen Mandantenschlüssel, jede Abfrage setzt ihn durch, und ein Manager von Marke A kann selbst mit einer konstruierten URL keinen Lead von Marke B lesen. Rollenbasierter Zugriff steuert, welcher Manager welchen Lead lesen darf, und Audit-Logs erfassen jeden Lese- und Schreibvorgang für die Compliance-Prüfung.
Der Datenschutz der Kunden ist von Tag eins an in die Plattform eingebaut. Der Lead-Erfassungsablauf ist regionsbewusst: Nutzer in der Europäischen Union erhalten einen granularen DSGVO-Einwilligungsbildschirm mit separaten Schaltern für Marketing-Follow-up und Produktanalytik; Nutzer in Kalifornien erhalten im selben Ablauf die CCPA-/CPRA-Offenlegung „Do Not Sell or Share My Personal Information". CRM-Datensätze unterliegen Aufbewahrungsfristen, Löschanfragen sind ein einzelner Backend-Job über alle drei Markenseiten, und das Audit-Log hält den Nachweispfad für das regulatorische Umfeld in den USA und der EU.
Compliance-Aufstellung: DSGVO-konform · ISO-27001-bereit · SOC 2 Type II in Vorbereitung · HIPAA-fähig · CCPA-berücksichtigt.
Eine fünfphasige Entwicklung, die Mosokna von drei auseinanderdriftenden Markenrechnern zu einer konsolidierten Multi-Tenant-Plattform mit CRM führte.
Drei Markenseiten-Rechner Zeile für Zeile auditiert, Geschäftsregeln in einen kanonischen Regelsatz extrahiert, Bug-Historie geprüft, DSGVO- + CCPA-Aufstellung kartiert, Multi-Tenant-Datenmodell entworfen.
Grundgerüst der Laravel-Preis-Engine, Konfigurator-Zustandsmaschine, REST-API-Vertrag, React- + Redux-Toolkit-Client, adressbasierte automatische Maßerkennung via OpenStreetMap.
Markenspezifische React-Themes, die aus einer Engine lesen, Balkontür-Konfigurator-Subtyp, CRM-Modul, Lead-Scoring, rollenbasierter Zugriff, Weiterleitung zur Manager-Beratung.
Multi-Tenant-Datenisolation auf Zeilenebene, Aufbewahrungsrichtlinien, regionsbewusste Einwilligungsabläufe, Paritäts-Harness, der über 4.000 Alt-Angebote gegen die neue Engine vergleicht, Gerüst für Drittparteienbereitschaft.
Umstellung über die drei Markenseiten, Altrechner stillgelegt, Onboarding des Vertriebsteams auf das CRM, Conversion-Funnel-Telemetrie, Korrekturschleife im ersten Zyklus über die US- und EU-Oberflächen.
Das CRM von Mosokna wurde so gebaut, dass das Vertriebsteam mit einem Posteingang arbeitet, nicht mit dreien. Jeder Lead trägt die Quell-Markenseite, den Konfigurator-Vollständigkeitsscore, den Status der Adressauflösung und den vollständigen Konfigurationsverlauf, den der Käufer aufgebaut hat — einschließlich abgebrochener Entwürfe, die die Zustandsmaschine des Konfigurators bei jedem Übergang als Snapshot festhält. Manager triagieren Leads nach Score, heiße Leads werden automatisch an Beratungsgespräche weitergeleitet, und warme Leads fallen in eine Follow-up-Kadenz mit Vorlagen, die die vom Käufer tatsächlich aufgebaute Konfiguration vorbefüllen. Das Lead-Scoring-Modell ist ein Konfigurationsobjekt, das der Manager anpassen kann, ohne Code anzufassen, sodass das Unternehmen einstellen kann, was „qualifiziert" bedeutet, während der Funnel reift. Ein Partnerkanal — Händler und Monteure, die den Konfigurator auf ihrer eigenen Seite unter ihrer eigenen Marke einbinden möchten — ist eine Multi-Tenant-Konfigurationszeile plus ein partnerspezifischer Preisadapter, kein separater Aufbau. Das gesamte Subsystem ist so gestaltet, dass ein künftiger Finanzierungspartner, eine B2B-Vertragspreisstufe für die Vereinigten Staaten und die Europäische Union oder eine Marktplatz-Übergabe an große Home-Improvement-Ketten eine Konfigurationsänderung gegen die Engine und den Entitlement-Service ist, kein Code-Release.
Mosokna startete über die drei Markenseiten mit Storefronts, die in den Vereinigten Staaten und der Europäischen Union aktiv sind. Die englischsprachige Variante bedient Käufer in Kalifornien, New York, Texas, Florida und Washington in den USA sowie Käufer in den Niederlanden, Deutschland, Frankreich, Irland und Schweden in der EU, ohne eine separate Codebasis pro Region. Regionsspezifische Preisadapter führen Währung, Arbeitskostenmultiplikatoren und Steuerbehandlung ehrlich, und der Konfigurator zeigt unter jedem Angebot eine regionale Offenlegung an, sodass der Käufer sieht, was inbegriffen ist und was nicht, bevor der Preis fixiert wird. Einwilligungsabläufe sind auf der Client-Schicht regionsbewusst: Nutzer in der EU und im EWR erhalten einen granularen Einwilligungsbildschirm im DSGVO-Stil mit separaten Schaltern für Marketing-Follow-up; Nutzer in Kalifornien erhalten im selben Ablauf eine Offenlegung im CCPA-Stil „Do Not Sell or Share My Personal Information". Die Datenverarbeitungspraktiken sind für europäische Nutzer an der DSGVO und am Flickenteppich der US-Bundesstaaten-Datenschutzgesetze ausgerichtet — CCPA / CPRA (Kalifornien), VCDPA (Virginia), CPA (Colorado), CTDPA (Connecticut), UCPA (Utah), TDPSA (Texas) und Oregon CPA.
Konfigurator und CRM wurden parallel über US- und EU-Händlerregionen ausgerollt — Niederlande, Deutschland, Frankreich, Schweden und Irland für die EU-Abdeckung; US-Ost- und US-West-Händlergebiete für Nordamerika —, wobei die Leads jeder Region identisch gegen dieselbe Multi-Tenant-Datenbank bereitgestellt wurden. Der Matching-Service, der pro Lead das richtige Beratungsteam auswählt, betreibt zustandslose Worker, die sich für künftige Datenresidenz-Verpflichtungen unabhängig an EU- oder US-Regionen binden lassen. Das Engineering-Team hinter der Entwicklung sitzt über die MEZ verteilt und arbeitet an einem MEZ-Arbeitstag mit Überlappung mit der US-Ostküste (9–13 Uhr ET) für Vertriebsteam-Standups, herstellerseitige Koordination und Incident-Response — die Zeitzone, die einem US-Vertriebsteam und einem EU-Engineering-Team täglich vier Stunden Live-Überlappung ermöglicht.
Die aktive Roadmap der individuellen Softwareentwicklung für Mosokna umfasst eine Finanzierungspartner-Integration, die Ratenangebote innerhalb des Konfigurators anzeigt, eine B2B-Vertragspreisstufe mit Team-Verwaltung, ein Monteur-Übergabeportal für Partnerhändler und ein Konfigurator-Embed für Home-Improvement-Seiten von Drittanbietern. Eine Dach-und-Verglasung-Erweiterung, die dieselbe Multi-Tenant-Engine wiederverwendet, ist geplant, und das Entitlement-Subsystem ist bereits für die Mehrplatzzuweisung strukturiert. Die Infrastrukturpläne umfassen weitere Performance-Optimierung der Preis-Engine, ein internes Regressions-Harness gegen das Paritäts-Testset und eine künftige unabhängige Bereitschaftsbewertung, die in die Cloud-&-DevOps-Roadmap eingebettet ist.
Wenn Sie eine Angebotsplattform, einen Multi-Tenant-Konfigurator oder eine Konsolidierung planen, bei der mehrere auseinanderdriftende Rechner für Zielgruppen in den USA und der EU in einer Engine zusammenfallen müssen, haben wir diesen Stack durchgängig ausgeliefert und können den Entwicklungszeitplan deutlich verkürzen. Das Live-Produkt ist unter mosokna.ru verfügbar, und das Engineering-Team dahinter sitzt innerhalb der YuSMP Group. Wir arbeiten zum Festpreis für gut abgegrenzte MVPs 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 fokussiertes MVP zur Fensterangebotserstellung mit einer Laravel-Preis-Engine, einem React-Konfigurator, adressbasierter Suche, einem Warenkorb und einem grundlegenden CRM zur Lead-Verwaltung kostet in der Regel 120.000 bis 240.000 US-Dollar. Ergänzt man Multi-Tenant-Markenseiten, die sich eine Engine teilen, einen Balkontür-Konfigurator, regionale Preisadapter, Profil- und Zusatzoptionsbibliotheken sowie Integrationen in den Buchhaltungs-Stack des Händlers, bringt das eine voll ausgestattete Plattform auf 260.000 bis 520.000 US-Dollar. Die wesentlichen Kostentreiber sind die Konsolidierung der Preis-Engine-Logik, die Zustandsmaschine des Konfigurators und die Multi-Tenant-Datenisolationsschicht.
WordPress-Rechner-Plugins lassen sich schnell einsetzen, sperren jede Markenseite aber in ihre eigene Kopie der Preislogik — genau das Problem, das Mosokna vor dem Neuaufbau hatte: drei Seiten, drei auseinanderdriftende Rechner, drei Sammlungen angesammelter Bugs. Ein SaaS-Konfigurator löst das Engine-Problem, verliert aber jede Layout-, CRM- und Inhaltsentscheidung an die Vorlagen des Anbieters. Laravel Multi-Tenant gibt dem Unternehmen eine Engine, ein CRM und markenspezifische Layouts mit regionalen Preisadaptern, die denselben Audit-Trail teilen.
Der Käufer gibt eine Adresse ein; ein OpenStreetMap-Geocoding-Schritt löst sie zu einem Gebäude auf, und eine Typologiesuche anhand der Gebäudeserie zeigt die typischen Fenstermaße für diese Einheit an. Der Käufer bestätigt oder passt jedes Maß weiterhin millimetergenau an, bevor der Preis fixiert wird, doch die automatische Erkennung reduziert den Messaufwand für die häufigsten Gebäudeserien um eine Größenordnung. Wo keine Typologieübereinstimmung vorliegt, gibt der Käufer die Maße mit derselben Präzision und Validierung manuell ein.
Eine Angebotsplattform mit CRM erfasst echte personenbezogene Daten — Namen, Telefonnummern, Adressen, Konfigurationsverlauf —, daher haben die Pflichten erste Priorität. Der Lead-Erfassungsablauf zeigt Nutzern in der Europäischen Union einen granularen Einwilligungsbildschirm, der die DSGVO erfüllt, und Nutzern in Kalifornien im selben Ablauf eine CCPA-/CPRA-Offenlegung. CRM-Datensätze unterliegen Aufbewahrungsfristen, rollenbasierte Zugriffskontrollen regeln, welcher Manager welchen Lead lesen darf, und eine Löschanfrage ist ein einzelner Backend-Job über die gesamte Multi-Tenant-Datenebene.
Ein fokussiertes MVP mit einer Laravel-Preis-Engine, einem React-Konfigurator, adressbasierter Suche, einem Warenkorb, einem CRM-Modul und einer einzelnen Markenseite dauert in der Regel 16 bis 22 Wochen. Eine zweite und dritte Markenseite, die sich dieselbe Engine teilen, regionale Preisadapter, ein Balkontür-Konfigurator und die Weiterleitung zur Manager-Beratung kommen mit 6 bis 10 Wochen hinzu. Die auditbereite Härtungsphase — Multi-Tenant-Datenisolation, rollenbasierter Zugriff, Aufbewahrungsrichtlinien und DSGVO- + CCPA-Einwilligungsabläufe — wird häufig unterschätzt und sollte mit 3 bis 5 Wochen veranschlagt werden.
Verwandte Fallstudien
Offline-first-Ökosystem, das Papierjournale für die Reaktorprozesssteuerung ersetzt.
Fallstudie ansehen → Wohnungsrenovierung · WebNeu gestaltete, SEO-optimierte Website für ein Unternehmen für Wohnungsrenovierung und -gestaltung.
Fallstudie ansehen → AdTech · LeadgenerierungTilda-Landingpage mit Lead-Erfassung über Telegram-Bot — schneller Inbound-Funnel für ein Dienstleistungsunternehmen.
Fallstudie ansehen →