Shop-Betreiber kennen meist eine einzige Zahl: die auf der Hosting-Rechnung. Ein Jahr später stellt sich heraus, dass der Betrieb ein Vielfaches gekostet hat, nur verteilt auf Posten, die nie jemand zusammengezählt hat. Wir betreuen Online-Shops von der technischen Seite lange genug, um zu wissen, wo dieses Geld wirklich versickert. Selten im Server. Fast immer in Entscheidungen, die bei der Umsetzung getroffen wurden.
Inhaltsverzeichnis
Woraus sich die Betriebskosten eines Shops zusammensetzen
Die Jahresrechnung teilt man am besten in vier Schichten. Die erste ist die Infrastruktur: Server, Traffic, Domains, Zertifikate. Die zweite, Lizenzen und externe Dienste, also Plugins, Module, Zahlungs-Gateways, die Produktsuche, Werkzeuge für den E-Mail-Versand.
Die dritte Schicht ist die Arbeit der Menschen, die den Shop aktualisieren, überwachen und reparieren. Die vierte, ungeplante Ereignisse: eine Störung, eine erzwungene Migration der Shop-Version, ein Anbieter, der seine API ohne Rückfrage ändert. Betreiber schauen auf die ersten beiden, weil sie als wiederkehrende Rechnungen eintreffen. Und das Budget läuft dann bei der dritten und vierten aus dem Ruder, denn dort entstehen die Kosten unregelmäßig und meist im schlechtesten Moment.
Daraus folgt der Satz, den wir bei jeder Kalkulation wiederholen: die Betriebskosten eines Shops sind eine Funktion der Architektur, nicht der Hosting-Preisliste. Es lohnt sich außerdem, die feste, monatlich wiederkehrende Kostenposition von der wiederkehrenden Position mit unregelmäßigem Rhythmus zu trennen: Versionsmigration, Audit, Austausch einer Integration. Die zweite übersieht man leicht in der Planung, weil sie im jeweiligen Quartal schlicht nicht sichtbar ist. Dieselbe Logik gilt für die Betriebskosten einer Anwendung nach der Umsetzung, nicht nur für Shops.
Infrastruktur: Skalierbarkeit, die Sie das ganze Jahr bezahlen
Ein Shop wird für die Spitzenlast ausgelegt und zwölf Monate lang bezahlt. Black Friday und Dezember bestimmen die nötige Leistungsreserve, also steht den Rest des Jahres ein überdimensionierter Server herum, dessen Prozessor sich langweilt. Das ist der häufigste Posten, den man ohne Risiko für den Umsatz kürzen kann.
Die Alternative? Eine zustandslose Architektur mit Autoscaling, die das Entgelt von der Reservierung auf den tatsächlichen Verbrauch verlagert. Sie hat allerdings eine Voraussetzung: Sessions, Warenkörbe und Dateien müssen die Anwendungsmaschine verlassen und in einen gemeinsam genutzten Speicher umziehen. Ein Shop, der die Session lokal hält, skaliert nicht horizontal, selbst wenn die Infrastruktur es zuließe.
Cache und CDN senken die Rechnung für Rechenleistung, bringen aber eine eigene Klasse von Problemen mit. Invalidierung von Inhalten, Preisvarianten, individuelle Preise für B2B-Kunden, Sichtbarkeit der Lagerbestände: All das kann die Ersparnis auffressen, wenn jemand die Cache-Regeln nur schnell zusammengeschustert hat.
Dazu kommen die Sicherungskopien. Es zählt nicht, dass sie erstellt werden, sondern die Aufbewahrungsdauer und ein regelmäßiger Wiederherstellungstest. Die Kosten eines Backups zeigen sich erst dann, wenn die Wiederherstellung des Shops einen ganzen Tag dauert. Die Testumgebung behandeln wir ähnlich: als Budgetposten, nicht als Luxus, denn ohne sie landet jede Aktualisierung direkt auf der Produktion. Diese ganze Schicht beginnt damit, auf welchem Hosting für Websites und E-Mail der Shop überhaupt läuft.
Lizenzen, Plugins und Integrationen: die Kosten fremder Entscheidungen
Einen Shop auf kommerziellen Plugins kauft man einmal und verlängert ihn jedes Jahr. Die Lizenz läuft still aus, es kommen keine Aktualisierungen mehr, und die nicht verlängerte Komponente wird zur Sicherheitslücke, an die sich niemand erinnert, bis ein Schwachstellenscan läuft.
Der zweite Teil dieser Rechnung liegt außerhalb Ihrer Kontrolle. Eine geänderte Preisliste der Kurier-API, neue Gebühren des Zahlungs-Gateways, geänderte Limits im Lagersystem: Kosten, auf die der Shop keinen Einfluss hat und die er trotzdem tragen muss. Bewerten Sie die Abhängigkeit vom Anbieter deshalb schon bei der Wahl der Technologie, nicht später.
Integrationen mit ERP, WMS, Buchhaltung und Marktplätzen brauchen ständige Betreuung, denn APIs wechseln ihre Version, ohne nach der Bereitschaft des Shops zu fragen. Eine als veraltet markierte Version hat ein Abschaltdatum. Und dieses Datum kommt immer.
Ein typischer Fehler, den wir bei der Übernahme fremder Projekte sehen: mehrere Dutzend Plugins mit sich überschneidenden Funktionen, die niemand gefahrlos abschalten kann, weil unklar ist, welches eigentlich den Versand abwickelt. Besonders leicht passiert das in Shops auf Basis von WooCommerce, wo sich jede Funktion mit einer eigenen Erweiterung ergänzen lässt. Die Architekturentscheidung, die die Rechnung wirklich senkt, ist die umgekehrte: weniger Komponenten, jede mit einem klaren Verantwortlichen und einem vorgesehenen Aktualisierungspfad.
Arbeit des Teams: Aktualisierungen, Monitoring und Rufbereitschaft
Aktualisierungen des Shopsystems, der Plugins und der Abhängigkeiten sind laufende Arbeit, kein einmaliges Projekt. Je länger man sie aufschiebt, desto teurer wird es, denn statt einer Reihe kleiner Schritte entsteht eine große Migration über mehrere Versionen hinweg, samt Neuschreiben der Integrationen nebenbei.
Monitoring, Logs und sinnvolle Alarme verkürzen die Diagnose einer Störung von Stunden auf Minuten. Diese Investition rechnet sich beim ersten ernsten Zwischenfall, denn die Kosten eines Ausfalls in der Saison misst man in verlorenen Bestellungen, nicht in Arbeitsstunden.
Rufbereitschaft und eine zugesagte Reaktionszeit kosten Geld. Ihr Fehlen kostet ebenfalls, nur im denkbar schlechtesten Moment des Jahres. Ähnlich verhält es sich mit technischen Schulden: Code ohne Tests und Dokumentation erhöht den Preis jeder weiteren Änderung, bis eine kleine Anpassung eine Woche vorsichtiger Analyse erfordert.
Das Minimum, das in einem Shop regelmäßig passieren sollte:
- Sicherheitsaktualisierungen des Shopsystems, der Plugins und Abhängigkeiten, zuerst auf der Testumgebung
- Test der Wiederherstellung aus dem Backup, mit Messung der Zeit, bis der Shop wieder läuft
- Durchsicht von Logs und Alarmen: Integrationsfehler, fehlgeschlagene Zahlungen, langsame Datenbankabfragen
- Kontrolle der Performance der wichtigsten Pfade: Produktliste, Produktseite, Warenkorb, Bestellabschluss
- Prüfung der Verlängerungstermine von Lizenzen, Zertifikaten und Zugangsschlüsseln
Sicherheit, Daten und Compliance als Budgetposten
Zertifikate, Trennung der Umgebungen, Rotation der API-Schlüssel, Durchsicht der Administratorkonten nach dem Ausscheiden eines Mitarbeiters. Einzeln Kleinigkeiten, in der Summe aber im Budget sichtbar. Vernachlässigt werden sie zum Zwischenfall.
Personen- und Zahlungsdaten bringen eigene Anforderungen mit: eine Aufbewahrungsrichtlinie, Anonymisierung alter Bestellungen, Bearbeitung von Löschanfragen, Protokollierung der Zugriffe auf Kundendaten. Ein Shop, der alles unbegrenzt aufbewahrt, zahlt nicht nur für Speicherplatz. Er zahlt auch für das Risiko.
Die Rechnung für einen Zwischenfall ist weit mehr als die Reparatur. Dazu kommen Umsatzausfall, Kommunikation mit den Kunden, Bearbeitung der Anfragen und der mühsame Wiederaufbau des Vertrauens. Deshalb planen wir Audits und Sicherheitstests im Voraus, statt sie nach einem Einbruch zu starten.
Ein eigenes Thema: die Performance. Core Web Vitals und Antwortzeiten verschlechtern sich von selbst, während Katalog, Bestellhistorie und Analysedaten wachsen. Ein Shop, der zum Start schnell war, wirkt nach zwei Jahren mitunter schwerfällig, obwohl niemand etwas kaputt gemacht hat.
Was die Rechnung wirklich treibt: Skalierung, Änderungstempo und Integrationen
Über die Jahreskosten entscheiden drei Variablen: das Volumen an Traffic und Bestellungen, das Tempo der Änderungen im Shop sowie die Zahl der Systeme, mit denen der Shop spricht. Der Rest ergibt sich daraus.
Ein Shop mit einem Großhändler und einem Kurierdienst wird völlig anders betrieben als eine Plattform, die an ein ERP, mehrere Marktplätze und ein Treueprogramm angebunden ist. Jede Integration ist ein eigener Fehlerpunkt, mit eigenem Datenformat und eigenem Änderungsplan auf Anbieterseite.
Auch das Produktdatenmodell hat seinen Preis. Umfangreiche Varianten, Preislisten pro Kundengruppe und Mehrsprachigkeit erhöhen die Kosten jeder späteren Änderung, weil sie viele Stellen zugleich berühren. Das sollte man vor der Umsetzung wissen, nicht mittendrin.
Die Migration auf ein anderes Shopsystem ist manchmal eine Kostenentscheidung, keine technologische. Sie lohnt sich, wenn die aktuelle Plattform konkrete Geschäftsprozesse blockiert. Sie ist eine Flucht vor dem Problem, wenn die eigentliche Schwierigkeit im Chaos der Integrationen lag, denn das zieht mit den Daten um. Eine gelungene Umsetzung unterscheidet sich von einer misslungenen durch eines: ob sie sich ohne den Autor des ursprünglichen Codes betreiben lässt.
Wie Sie das Betriebsbudget für das nächste Jahr planen
Beginnen Sie mit einer Inventur. Eine Liste der Komponenten, Integrationen, Lizenzen und ihrer Verlängerungstermine kostet ein paar Stunden und beseitigt die meisten Überraschungen, weil sie schwarz auf weiß zeigt, was wann ausläuft.
Planen Sie danach eine Reserve für Ereignisse, die der Art nach vorhersehbar sind, dem Termin nach aber nicht: eine API-Änderung des Anbieters, eine erzwungene Aktualisierung, einen Sicherheitsvorfall. Es geht nicht um Kaffeesatzleserei, sondern darum, dass so eine Situation die Weiterentwicklung des Shops nicht ein Quartal lang blockiert.
Und trennen Sie endlich das Betriebsbudget vom Entwicklungsbudget. Wenn beide aus einem Topf kommen, gewinnen neue Funktionen immer gegen unsichtbare Stabilität, bis zum ersten längeren Ausfall. Wer bei null beginnt, sollte diesen Posten damit vergleichen, wie viel eine Website kostet allein in der Umsetzung.
Der Kern lautet: die Betriebskosten eines Shops sinken durch eine einfachere Architektur und Regelmäßigkeit der Arbeiten, nicht durch das Kürzen der Hosting-Ausgaben. Weniger Komponenten, klare Verantwortlichkeiten und ein vorhersehbarer Aktualisierungsrhythmus bringen eine Ersparnis, die man auf der Rechnung nicht sieht, dafür aber in einer ruhigen Saison.
Wenn Sie prüfen möchten, wo in Ihrem Shop die tatsächlichen Kosten stecken, melden Sie sich bei uns. Wir übernehmen Audits bestehender Projekte, Integrationen mit Unternehmenssystemen, Automatisierungen und die Modernisierung von Systemen, die dem Geschäft nicht mehr folgen können.
