Code-Audit und Architektur-Doku
Vollständige Sichtung des Eigencodes, der Plugin-Landschaft und der Schnittstellen. Architektur und Datenflüsse in einem internen Wiki dokumentiert - damit nie wieder das Wissen mit einer Person geht.
Ein WooCommerce-Shop im Konsumgüterbereich, der über Jahre gewachsen ist - rund 80 Bestellungen am Tag, ein eigener Versand, eine angeschlossene Warenwirtschaft. Als der hauseigene Entwickler das Unternehmen verließ, war niemand mehr da, der den Shop verstand. Wir haben übernommen, stabilisiert und betreuen ihn heute rund um die Uhr - auch am Black Friday.
Der Inhaber kam zu uns, nachdem der hauseigene Entwickler nach acht Jahren das Unternehmen verlassen hatte. Dokumentation gab es kaum, der Code war über die Jahre organisch gewachsen, eigene Plugins lagen ohne Quelltext-Kommentare im System.
Drei Mal pro Jahr fiel der Shop für mehrere Stunden aus, meist nach automatischen Plugin-Updates über Nacht. Die Anbindung an die Warenwirtschaft brach regelmäßig - Bestellungen mussten dann von Hand übertragen werden. Die mobile Ladezeit lag im roten Bereich, eine Optimierung war seit Jahren überfällig.
Was der Inhaber wollte: ein Partner, der den Shop versteht, ihn stabilisiert und im Notfall innerhalb von Minuten erreichbar ist - auch und gerade an Verkaufs-Spitzentagen.
Bei einem produktiven Shop können wir nichts umbauen, ohne ihn zuerst zu verstehen. Wir haben genau in dieser Reihenfolge gearbeitet.
Vollständige Sichtung des Eigencodes, der Plugin-Landschaft und der Schnittstellen. Architektur und Datenflüsse in einem internen Wiki dokumentiert - damit nie wieder das Wissen mit einer Person geht.
Eine vollwertige Kopie des Live-Shops, in der wir Updates, Plugin-Wechsel und Code-Änderungen risikofrei testen können, bevor etwas live geht.
Die Schnittstelle zur Warenwirtschaft mit sauberem Fehler-Handling und automatischer Wiedervorlage neu gebaut. Seitdem keine manuelle Übertragung mehr.
Object-Cache, Bild-Pipeline, kritische CSS-Pfade, Datenbank-Indizes. PageSpeed-Mobile von 38 auf 87, Time-to-Interactive auf der Produktseite halbiert.
Bezahl-Routen geprüft, Zahlungs-Plugin auf aktuellen Stand, Brute-Force-Schutz auf Login- und Checkout-Routen, regelmäßige Schwachstellen-Scans.
Tägliche, redundante Cloud-Sicherungen inklusive Bestelldatenbank. Wiederherstellung halbjährlich auf Staging getestet - dokumentierter, gemessener Prozess.
Ein Shop, der Umsatz macht, hat andere Pflege-Anforderungen als eine Visitenkarten-Webseite. Wir betreuen ihn entsprechend dichter.
Synthetisches Monitoring des kompletten Bestellprozesses - vom Produktaufruf bis zur Bestellbestätigung. Wenn ein Schritt klemmt, sehen wir es, bevor der erste Kunde es meldet.
WooCommerce, Theme, Zahlungs-Plugin, Versand-Module - jedes Update zuerst auf Staging, mit Funktionstest des Bestellprozesses, dann live in einem Niedriglast-Fenster.
Ein konsolidierter Bericht: Verfügbarkeit, durchschnittliche Ladezeit, Conversion-Rate, korrelierte Umsatzentwicklung. Sichtbar machen, was Wartung wirklich bringt.
Erreichbar rund um die Uhr, auch an Wochenenden und Feiertagen. Vor Verkaufs-Spitzen (Black Friday, Saison-Launches) zusätzliche Bereitschaft mit definiertem Reaktions-SLA.
Inhalts- und Funktionswünsche, Standardanpassungen, Schätzungen - alles im Support-System, nachvollziehbar.
Eine separate Notfall-Nummer für „der Shop ist gerade nicht erreichbar“. Reaktion in Minuten, nicht Stunden.
Vor Black Friday, Weihnachten oder eigenen Aktionen: Lasttest auf Staging, Caching-Profile, Bereitschaftsplan.
Monatliche Wartungspauschale mit definiertem Leistungsumfang, Notfall-SLA mit Reaktionszeit. Keine Überraschungen auf der Rechnung.
Freitagabend, 19:14 Uhr. Unser Monitoring schlägt Alarm: Die Antwortzeiten der Produktseiten klettern, der Bestellprozess wird langsamer, einzelne Checkout-Versuche brechen ab. Last fast doppelt so hoch wie geplant - eine Rabattaktion war über einen Newsletter-Sonderversand größer angekommen, als das Marketing erwartet hatte.
Innerhalb von acht Minuten waren unsere zwei Bereitschafts-Entwickler im System. Diagnose: Die Object-Cache-Konfiguration kam unter dieser Last an ihre Grenze, ein bestimmter Cache-Key wurde von zu vielen Worker-Prozessen gleichzeitig invalidiert.
Lösung: erhöhte Cache-TTL für die betroffenen Produkt-Routen, gleichzeitig eine ergänzte CDN-Regel für die Bestellprozess-Endpunkte, kurzer Smoke-Test im Echtbetrieb. Antwortzeiten wieder im grünen Bereich nach knapp vierzig Minuten ab erstem Alarm.
Als unser Entwickler aufgehört hat, hatte ich ein paar schlaflose Nächte. Heute kann ich sagen: Ich denke nicht mehr täglich an den Shop. Er läuft, jemand kümmert sich, ich kann mich auf das Geschäft konzentrieren.
Wir schauen uns Ihren Shop unverbindlich an - was läuft gut, was wäre zu sanieren, was empfehlen wir für die nächsten Monate. Das Erstgespräch ist kostenlos.