WooCommerce oder Laravel: welche Onlineshop-Plattform wann passt

Über die Plattform entscheidet nicht die Funktionsliste des ersten Tages – Lager, B2B-Preise und Mehrsprachigkeit bauen wir auf beiden –, sondern wer Ihre nächste Änderung bestimmt und was sie kostet.

Eine Technologiefrage, deren Antwort keine Funktionsliste ist

Das Gespräch beginnt fast immer gleich: Der Kunde hat rund siebenhundert Produkte, drei Preisstufen für Wiederverkäufer, von denen jeder in seinem Profil nur seinen eigenen Preis sieht, und eine Buchhaltung in Visma Horizon, in der der Lagerbestand die Wahrheit ist und der Shop ihn nur abbildet. Die Frage, die er stellt, lautet: WooCommerce oder Laravel? Die Antwort, die er erwartet, ist eine zweispaltige Liste, in der auf der einen Seite etwas steht, was auf der anderen fehlt – eine Liste, die wir nicht haben und die niemand hat, der beide Plattformen tatsächlich baut.

Lagermodul mit Bestandssynchronisation in Echtzeit, B2B-Preisstufen, Rabattsystem, Mehrsprachigkeit und Datenmigration bauen wir auf beiden Plattformen, und der Preis in unserer Preisliste hängt nicht davon ab, was darunter liegt: Die Basic-Version eines Onlineshops kostet 4.500 € und die Pro-Version 9.500 €, auf WooCommerce genauso wie auf Laravel. Genau diese fünf Zeilen trennen Basic von Pro, nicht die Plattform darunter; der Administrationsbereich ist in der Preisliste bereits unter Basic aufgeführt, Mehrwährungsfähigkeit dagegen in keiner der beiden Versionen – sie wird gesondert vereinbart, wieder auf jeder der beiden Plattformen.

Daraus folgt etwas sehr Praktisches: Eine Plattform, die Ihnen mit der Funktionsliste des ersten Tages verkauft wird, wird mit etwas verkauft, das auf beiden Wegen zu haben ist, und ein Vergleich, der mit einer solchen Liste beginnt, ist zu Ende, bevor er angefangen hat. Interessant wird die Frage einen Schritt weiter: Wer entscheidet darüber, was Ihr Shop nächstes Jahr können wird, und wie lange wartet diese Entscheidung in der Schlange bei jemand anderem?

Im ersten Jahr tun beide Plattformen das, wofür Sie bezahlt haben, denn in beiden Fällen hat es gerade jemand gebaut; im zweiten Jahr ändert sich der Prozess – Großhandel kommt dazu, ein zweites Lager, die Pflicht, maschinenlesbare Rechnungen auszustellen, oder schlicht eine andere Rabattordnung –, und von diesem Moment an kosten die beiden Wege unterschiedlich. Auf der Erweiterung eines fremden Herstellers ist jede spätere Änderung ein Umbau in gemieteten Räumen: Die Regeln Ihres Prozesses wohnen im Einstellungsdialog eines anderen und ziehen nach dem Release-Plan eines anderen um. Auf eigenem Code ist dasselbe eine Arbeit, für die es in der Preisliste einen Satz gibt, und abzustimmen ist nur ihre Priorität gegenüber dem Rest der Liste.

Was WooCommerce gut macht

WooCommerce setzen wir selbst in Kundenshops ein, sooft der Prozess dazu passt, und es ist das meistgenutzte E-Commerce-System in den Erhebungen von W3Techs: Am 6. August 2026 lief es auf 8,2 % aller Websites und machte 48,5 % aller dort erfassten E-Commerce-Systeme aus. Wichtiger als die Zahl ist, woraus sie gerechnet ist – ein Anteil an den erfassten Systemen, nicht an den Shops der Welt und ganz sicher nicht am Umsatz des Onlinehandels –, und dahinter steht WordPress mit 41,2 % aller Websites.

Das Plugin-Verzeichnis auf WordPress.org zeigte am selben Tag WooCommerce in Version 11.0.0, aktualisiert am 4. August, mit der Schätzung „7+ million active installations“ – mehr als sieben Millionen aktive Installationen –, und zur Vorsicht beim Lesen rät der Hersteller selbst: Die Nutzungserfassung ist in dem von WordPress.org heruntergeladenen Kern standardmäßig ausgeschaltet, deshalb weiß niemand, auch Automattic nicht, wie viele Shops tatsächlich Handel treiben; die Zahl ist die Obergrenze der Installationen und nicht die der Händler.

Auf der eigenen Preisseite beschreibt sich WooCommerce als quelloffene Plattform ohne Plattformgebühr und mit 0 % Umsatzbeteiligung: Sie zahlen nicht dafür, dass Sie verkaufen, und nicht dafür, dass der Umsatz wächst. Katalog, Bestellliste und Rabatteinstellungen sehen zudem aus wie der übrige WordPress-Administrationsbereich, den Ihr Team höchstwahrscheinlich schon ohne Schulung bedienen kann.

Das stärkste Argument für WooCommerce verschwindet in Wettbewerbsvergleichen fast immer, und das ist der automatische Patch: Am 2. März 2026 wurde eine Sicherheitslücke in der Store API veröffentlicht, die die Versionen 5.4 bis 10.5.2 betraf und es erlaubte, mit einer gefälschten Anfrage ein Administratorkonto anzulegen; gefunden hat den Fehler jemand anderes und nicht die Shopbetreiber; die Korrektur wurde über 52 betroffene Versionen zurückportiert; und noch am selben Tag ab 14:00 Uhr UTC verteilte sie sich automatisch an alle Shops, in denen automatische Updates eingeschaltet sind, ohne Rechnung. Diese Einstellung ist allerdings nicht selbstverständlich, und genau sie richtet im Wartungsvertrag ein Mensch ein und überwacht sie; wie WordPress-Websites gehackt werden und was dann zu tun ist, steht in unserem Beitrag über eine gehackte WordPress-Website.

Die Empfehlung hat sich deshalb nicht geändert und steht auch auf unserer Leistungsseite: für einen sehr kleinen Onlineshop mit Standardprozessen – WooCommerce. Einem Shop mit hundert Produkten, einem Preis, einem Lager und einer Zahlungsart bringt eine individuelle Plattform nichts, wofür sich die Differenz zu zahlen lohnte, und die teurere Variante zu verkaufen, wenn die günstigere dasselbe leistet, bedeutet einen unzufriedenen Kunden mehr und keine einzige Empfehlung.

Taugt WooCommerce für Zahlungen und Versand in Lettland?

Ja. Versand und Zahlungen in Lettland sind nicht die Stelle, an der ein fertiger Onlineshop aufhört, und gegenteilige Warnungen sind meist unbegründet: Omniva veröffentlicht fertige Module für sechs Plattformen – WooCommerce, Shopify, PrestaShop, OpenCart, Magento und Mozello – und daneben eine dokumentierte OMX-Schnittstelle, über die Sendungsdaten, Etiketten, Tracking-Ereignisse und Paketautomatenlisten in allen drei baltischen Staaten laufen; Voraussetzung dafür ist ein Firmenvertrag und kein Programmierer. DPD Baltics pflegt sein WooCommerce-Plugin im Verzeichnis von WordPress.org selbst – Version 1.2.91, mehr als 2.000 aktive Installationen –, und es deckt Paketautomaten, Kurier, Etiketten, Manifeste und Nachnahme ab; ebendort stehen auch die öffentliche Bewertung von 2,7 von 5 und Nutzerrezensionen, die über Konflikte mit anderen Versand-Plugins klagen.

MakeCommerce, hinter dem die Maksekeskus AS steht, liefert mit einem einzigen Vertrag die Bank-Links (Direktzahlung im Online-Banking) von Swedbank, SEB, Citadele und Luminor, Karten, Apple Pay und Google Pay und gleich daneben den Versand über Omniva, DPD, Venipak und Unisend; sein WooCommerce-Plugin hat mehr als 3.000 aktive Installationen und wurde zuletzt im Juni 2026 aktualisiert. Klix by Citadele, betreut von der Bank selbst, veröffentlicht offizielle Plugins für sechs Plattformen, darunter WooCommerce ab Version 3.5 – die Behauptung, ein fertiger Shop könne in Lettland kein Geld annehmen, wäre also schlicht falsch.

Die andere Seite derselben Sache ist, dass diese Dienstleister nicht den Plugins gehören: MakeCommerce, Omniva und DPD veröffentlichen Schnittstellen und nicht bloß Module, und in unserer Preisliste steckt die Zahlungsanbindung – MakeCommerce und Stripe – bereits in der Basic-Version für 4.500 €, unabhängig davon, welche Plattform darunter liegt. Integrationen mit Horizon, Jumis, Latvijas Pasts, Omniva und DPD sind eine Zeile der Shop-Leistung und kein Aufschlag für Laravel, und mit den Versand-APIs von Omniva, Latvijas Pasts, DPD und Venipak arbeiten wir regelmäßig; die lettische Versand- und Zahlungsschicht ist damit weder ein Argument für noch gegen einen der drei Wege.

Wo in Lettland die Arbeit wirklich steckt

Kompliziert wird es dadurch, dass Visma Horizon, Jumis und Directo jeweils eine eigene REST-Schnittstelle veröffentlichen – die Dokumentation von Directo beschreibt die Autorisierung über den Header X-Directo-Key und den Zugriff auf Artikel, Bestellungen, Kunden, Rechnungen, Bestände und Preisformeln –, doch eine veröffentlichte Schnittstelle ist noch keine Integration: Jemand muss zusammenbringen, was der Shop ein Produkt nennt, mit dem, was die Buchhaltung als Artikelstammsatz führt, und entscheiden, welches der beiden Systeme in der Sekunde, in der der Käufer den Knopf drückt, die Wahrheit über den Bestand hält. Wer eine Uhr hat, weiß, wie spät es ist; wer zwei hat, weiß es nie – und zwei Orte für denselben Bestand sind genau das. Diese Arbeit ist auf jeder Plattform individuell, und mit Horizon und Jumis machen wir sie regelmäßig.

Darüber steht ein datierter Rechtsfakt mit einer Falle darin: Die strukturierte elektronische Rechnung ist gegenüber staatlichen Stellen seit dem 1. Januar 2025 Pflicht, im Geschäftsverkehr zwischen Unternehmen wird sie es am 1. Januar 2028 – nach den Regeln des lettischen Buchhaltungsgesetzes und im Format LVS EN 16931-1:2017. Die Falle ist das Datum: Ursprünglich war 2026 vorgesehen, weshalb Presseartikel aus dem Jahr 2024 bis heute die falsche Frist nennen; nachsehen sollte man deshalb beim lettischen Finanzministerium auf der Seite zur strukturierten elektronischen Rechnung und nicht in den Nachrichten, denn für einen Shop, der an Unternehmen verkauft, wird den Weg zur maschinenlesbaren Rechnung auf jeder Plattform jemand bauen müssen – gleich, welches Jahr sich am Ende als das richtige erweist.

WooCommerce oder Laravel: welcher der drei Wege ist Ihrer?

Vergleiche, die diese Wahl als zwei Knöpfe präsentieren, lassen genau den Weg aus, den wir am häufigsten verkaufen, denn es sind in Wirklichkeit drei; sie unterscheiden sich darin, wie groß der Teil Ihres Prozesses ist, der in Code lebt, den Sie selbst ändern können, und die Wahl zwischen ihnen ist eine Entscheidung darüber, wo Ihre Preis- und Bestellregeln künftig liegen: im Einstellungsdialog, in Ihrem eigenen Repository oder auf halbem Weg dazwischen.

Der erste Weg ist ein fertiges Werkzeug mit fertigen Erweiterungen – WooCommerce oder OpenCart, das wir bestehenden Shops ebenfalls anbieten. Im Kern von WooCommerce gibt es zwei Preisfelder, den regulären und den Aktionspreis, eine Bestandszahl je Produkt oder Variante und drei Zahlungsarten, von denen keine Geld online entgegennimmt; deshalb sind der Preis für eine bestimmte Kundengruppe, Mengenrabatte, die Umwandlung eines Angebots in eine Bestellung, die Umsatzsteuerbefreiung und Bestände in mehreren Lagern jeweils ein eigener Kauf von einem eigenen Hersteller mit einem eigenen Jahresabo. Dieser Weg ist der schnellste und sehr oft der richtige, und sein Preis ist nicht das Geld, sondern dass die Regeln Ihres Prozesses fortan im Einstellungsdialog eines fremden Herstellers wohnen.

Der zweite Weg taucht in Vergleichen kaum auf, obwohl wir ihn am häufigsten verkaufen: ein fertiges Werkzeug mit unserem eigenen Code darüber. WooCommerce ist quelloffener PHP-Code, deshalb lassen sich eine Preistabelle für Wiederverkäufer, eine Kreditprüfung oder eine Bestandsreservierung neben dem Kern schreiben, statt sie als Plugin zu kaufen, und Lizenzen gibt es dafür nicht – es gibt Stunden –, zu dem Preis, dass dieser Code an den Update-Takt von WooCommerce gebunden bleibt und daran, wie diese Plattform Bestellungen speichert. Einen erheblichen Teil dessen, was in unserer Preisliste Pro-Version für 9.500 € heißt, macht genau diese Arbeit aus, und hier liegt der größte Teil unserer eigenen Shops.

Der dritte Weg ist unsere eigene Plattform, in der Katalog, Warenkorb, Kasse und Preislogik von der leeren Fläche aus um Ihren Prozess herum geschrieben werden; das ist der teuerste Anfang und der einzige, in dem keine Annahme eines fremden Herstellers darüber steckt, was ein Produkt ist und wann eine Bestellung zur Bestellung wird. Innerhalb des dritten Wegs gibt es eine Abzweigung: Bagisto und Lunar sind MIT-lizenzierte Laravel-Commerce-Pakete – am 6. August 2026 auf GitHub mit 27.943 beziehungsweise 3.588 Sternen –, die Katalog und Warenkorb bereits geschrieben mitbringen, im Tausch gegen eine weitere externe Abhängigkeit, deren Takt nicht in Ihren Händen liegt. Diesen Weg gehen wir nicht.

Was kosten WooCommerce-Plugin-Lizenzen pro Jahr?

Für einen Shop mit siebenhundert Produkten und drei Wiederverkäuferstufen kostete der erste Weg am 6. August 2026 270 € im Jahr für zwei öffentliche Preise plus einen unbekannten dritten. Dynamic Pricing gibt für 113 € im Jahr Mengen- und Rollenrabatte; das von Addify entwickelte B2B for WooCommerce gibt für 157 € im Jahr Rollenpreise, Staffelpreise, die Umwandlung eines Angebots in eine Bestellung, die Umsatzsteuerbefreiung sowie nach Rolle eingeschränkte Zahlungs- und Versandarten; für Bestände in mehreren Lagern ist im Kern dagegen nichts vorgesehen, weshalb ein drittes kostenpflichtiges Plugin hinzukommt, etwa Addify Multi Inventory Management, für das der Hersteller keinen öffentlichen Jahrespreis nennt.

Diese 270 € im Jahr sind etwas mehr als fünf Entwicklungsstunden, denn eine Entwicklungsstunde kostet in unserer Preisliste 50 €, und für Funktionen, die einen Hersteller, eine Dokumentation und Updates haben, ist das billig. Ein Preis, den Sie vor dem Gespräch nicht kennen, ist im Kostenvoranschlag allerdings keine Zeile: Das Lager-Plugin hebt diese Zahl an, und um wie viel, hängt von dem Angebot ab, das Ihnen zugeht, nachdem Sie die Zahl der Lager und das Bestellvolumen genannt haben.

Bei einem anderen Shop stehen andere Zeilen: Wer Abonnements, Buchungen und Mitgliedsstufen verkauft, zahlt zu denselben Marktplatzpreisen für WooCommerce Subscriptions 245 € im Jahr, für Bookings 218 €, für Memberships 175 €, für AutomateWoo 140 € und für Product Add-Ons 70 € – zusammen 848 € im Jahr. In fünf Jahren sind das, wenn die Preise nicht steigen, 4.240 €: fast der ganze Preis der Basic-Version, die in unserer Preisliste bei 4.500 € liegt, und fast die Hälfte der Pro-Version für 9.500 €. Diese Zeile amortisiert sich nicht, denn sie gilt für eine Website, für ein Jahr, und wird jedes Jahr neu bezahlt.

Dieselbe Zahl andersherum sind knapp 85 Entwicklungsstunden zu 50 €, und die bleiben in Ihrem Code und Ihrem Eigentum, statt in der Rechnung des nächsten Jahres wieder aufzutauchen. Die konkreten 848 € sind zudem die Rechnung eines Shops für Abonnements, Buchungen und Mitgliedschaften und keine Norm – eine solche gibt es hier nicht, und jeder Shop rechnet diese Zeile aus seinem eigenen Prozess zusammen. Die Lizenzzeile kommt außerdem zum Bau hinzu und nicht an seine Stelle: In beiden Fällen hat jemand den Shop zuerst gebaut, und nur in einem der beiden Fälle kommt für das Gebaute im nächsten Januar wieder eine Rechnung.

Was die Rechnung tut, wenn sie nicht bezahlt wird

Wird das Abo nicht verlängert, sagt die Dokumentation von WooCommerce.com es direkt: „the extension or theme remains installed on your site but will no longer receive updates“ – die Erweiterung bleibt installiert, der Shop läuft weiter, und weg sind allein die Updates. Die Folge einer nicht verlängerten Lizenz ist deshalb kein Ausfall, den man am selben Tag bemerkt, sondern ein nicht mehr korrigiertes Stück Code, das weiterhin Zahlungen verarbeitet; ein Abo deckt zudem eine Produktions- und eine Entwicklungsinstanz ab, und Subdomains zählen gesondert.

Eine Zeile verhält sich anders und auf beiden Seiten gleich: Der Buchhaltungskonnektor ist meist keine Lizenz, sondern ein Abo, das mit der Zahl der Bestellungen steigt – MyWorks Xero Sync beginnt auf dem WooCommerce-Marktplatz bei einer kostenlosen Stufe, und danach bestimmt das Volumen den Preis, weshalb diese Zeile genau dann wächst, wenn der Shop wächst. Eine individuelle Plattform nimmt sie nicht weg, sondern ändert, wer den Konnektor pflegt, und bei uns sind das Stunden; aufblähen muss man die Zeilen ebenso wenig: Mehrsprachigkeit kostet nicht automatisch 99 € im Jahr für WPML Multilingual CMS, denn neben WPML steht auch Polylang – die günstigere WPML-Lizenz Multilingual Blog für 39 € unterstützt E-Commerce aber nicht, sodass die Wahl zwischen 39 € und 99 € für einen Shop gar nicht besteht.

Warum der Unterschied erst im zweiten Jahr auftaucht

Dass der Preis von Änderungen eine reale und keine theoretische Ausgabe ist, zeigt die Plattform selbst: Seit 2023 hat WooCommerce zwei tragende Teile ausgebaut, eine Betafunktion zurückgezogen und eine Voreinstellung geändert. Die Legacy REST API verschwand am 11. Juni 2024 mit Version 9.0 aus dem Kern, nachdem sie seit Version 2.6 im Jahr 2016 als veraltet galt; das eingebaute Gateway PayPal Standard wurde in Version 8.9 im Mai 2024 entfernt; die Betaversion des Produkteditors fiel in Version 11.0 weg, die am 4. August im Verzeichnis erschien; die Bestellspeicherung HPOS dagegen wurde in Version 8.2 im Oktober 2023 zur Voreinstellung für neue Installationen und rührt bestehende Shops nicht an, solange sie niemand migriert.

Vor diesem Hintergrund stehen in den zwölf Monaten bis zum 5. August 2026 in der Rubrik Advisories des WooCommerce-Entwicklerblogs 37 Einträge – ungefähr drei im Monat –, und jeder davon ist gegen jede im Shop installierte Erweiterung zu prüfen, was ein Shop mit vier Plugins mühelos aufnimmt, ein Shop mit zwanzig aber nicht mehr. Der Stapel wächst außerdem nicht an einem Tag: Plugins kommen einzeln dazu, jedes für sich ist eine völlig vernünftige Entscheidung, und die Multiplikation der zu prüfenden Kombinationen geschieht leise.

Zehn Plugins sind nicht zehn Bauteile, sondern zehn Verträge, von denen jeder für sich enden kann, und der Eigentümer wechselt auch dann, wenn dem Code nichts fehlt. Am 31. Oktober 2025 schaltete der Bewertungsdienst Judge.me seine WooCommerce-Integration ab, zusammen mit Square, Squarespace, BigCommerce, Duda und PrestaShop: An die Daten kam man noch bis zum 19. November, danach wurde der Zugang endgültig entfernt, und Bewertungsvideos waren im Export nicht enthalten, sodass ein über Jahre aufgebautes Marketing-Asset zum Teil hinter der Tür blieb. Überzeugender sind die ruhigen Fälle: 2019 kaufte Automattic die Firma Prospress, die WooCommerce Subscriptions und AutomateWoo geschrieben hatte, 2020 kaufte GoDaddy die Firma SkyVerge, deren mehr als sechzig Plugins von über 100.000 Händlern genutzt wurden, und beide Übernahmen gingen, soweit sich das öffentlich beurteilen lässt, für die Händler gut aus. Die Frage ist nicht der Schaden, sondern dass der Eigentümer eines Bestandteils Ihres Shops ohne Ihr Zutun wechseln kann.

Wie groß dieses Risiko tatsächlich ist

Der Maßstab relativiert es, und die Zahlen sind hier unsere eigenen: In einer Auszählung vom 6. August 2026 lieferte die Plugin-API von WordPress.org 7.764 Plugins mit dem Schlagwort „woocommerce“, von denen 23,1 % seit zwei Jahren oder länger nicht aktualisiert wurden; in derselben Auszählung sitzen aber 10.809.800 aktive Installationen auf Plugins, die innerhalb der letzten sechs Monate aktualisiert wurden, und nur 208.790 auf solchen, die seit mehr als drei Jahren unberührt sind. Plugins mit 10.000 und mehr Installationen, die zwei Jahre ohne Update geblieben sind, gibt es in derselben Auszählung genau sechs.

Das aufgegebene Plugin ist fast nie das populäre, das alle kennen: Das Risiko sitzt in dem einen schmalen Modul, das genau Ihr Prozess verlangt – in den B2B-Preisstufen, im Lagerkonnektor, im Etikettengenerator eines bestimmten Versanddienstes –, und je stärker Ihr Prozess vom Durchschnitt abweicht, desto näher sind Sie an jenem Teil des Verzeichnisses, in dem das letzte Update aus dem vorletzten Jahr stammt. Diese Zeile lässt sich verkleinern, ohne etwas umzubauen: Im Wartungsvertrag machen das wir – weniger Plugins, konfigurierte Updates, Monitoring –, und ein Umbau ist erst dann die Antwort, wenn das Problem nicht mehr die Wartung ist, sondern dass der Prozess nirgends aufgeschrieben steht.

Wo die Datenstruktur von WooCommerce zu drücken beginnt

Die zweite Stelle, an der das zweite Jahr kostet, ist die Form der Daten, und zuerst jene Seite, auf der dieses Argument nicht mehr stimmt: Bestellungen liegen in neuen Installationen seit Version 8.2 in vier eigenen Tabellen, und die eigene Messung des Herstellers vom März 2023 zeigt, dass die neue Speicherung Bestellvorgänge beschleunigt und nicht bremst. Wo es drückt, ist die Produktseite, und am besten haben das die WooCommerce-Entwickler selbst geschrieben, als sie am 1. April 2019 die Performance-Verbesserungen der Version 3.6 erklärten: Produkte und Varianten laufen über das Beitragssystem von WordPress, in dem Post-Meta außerordentlich flexibel ist, aber „not that efficient when we need to sort or filter by many meta values at once“ – nicht besonders effizient, wenn gleichzeitig nach vielen Meta-Werten sortiert oder gefiltert werden muss. Die Antwort im selben Release war wc_product_meta_lookup, eine denormalisierte Hilfstabelle mit SKU, Preis und Bestandsstatus neben dem Post-Meta und nicht an seiner Stelle – die Grundform blieb also, wie sie war.

Die entsprechende Arbeit auf der Produktseite, woocommerce-product-tables-feature-plugin, lebt seit dem 16. Oktober 2017 nur auf GitHub und ist nicht aufgegeben – die letzten Änderungen stammen vom 31. Juli 2026 –, nur hält man sie bis heute nicht für stabil genug für das Verzeichnis von WordPress.org. Daneben steht wp_options, dessen Feld autoload standardmäßig keinen Index hat, dessen automatisch geladene Daten bei jedem Seitenaufruf gelesen werden, das WooCommerce selbst unter etwa 500 Zeilen zu halten empfiehlt und dessen Wachstum genau von Erweiterungen, Plugins und Themes verursacht wird – derselbe Stapel wie zuvor, nur von der Datenbankseite aus betrachtet.

Was Laravel einem Shop gibt und ein fertiges Werkzeug nicht

Laravel ist kein Shop und gibt auch nicht vor, einer zu sein: Es liefert benannte, dokumentierte und MIT-lizenzierte Bauteile, aus denen jemand einen Shop zusammensetzt; die Frage, die hier Geld wert ist, lautet deshalb nicht „ist das Framework gut“, sondern „welche Teile Ihres Prozesses werden endlich zu Ihren eigenen Tabellen und Ihren eigenen Jobs“. Im Shop eines Händlers sind das meist vier Zeilen – Preistabelle für Wiederverkäufer, Kreditlimit, Bestandsreservierung und Buchhaltungssynchronisation –, und genau diese kaufen Sie im fertigen Werkzeug bei vier verschiedenen Herstellern und stimmen sie danach untereinander ab.

Vorher gehört ehrlich gesagt, was dieser Weg nicht gibt, denn keine der vier Zeilen gibt Laravel selbst: Die offiziellen Starter-Kits liefern Authentifizierung und nichts weiter – weder Katalog noch Warenkorb noch Kassenschritt noch Lager –, und das einzige mitgelieferte Commerce-Paket ist Cashier, das Abo-Rechnungen auf der Seite von Stripe oder Paddle bedient und erwartet, dass Produkte mit Preisen im Dashboard des Zahlungsdienstes bereits beschrieben sind. Was Laravel gibt, ist die Form, in der diese vier Zeilen billig zu schreiben und später noch billiger zu ändern sind.

Queues, Transaktionen und Ihre eigene Datenbankstruktur

Das erste Bauteil sind die Queues (Warteschlangen für Hintergrundarbeit): eine Schnittstelle über mehrere Engines – Redis, Datenbank, Amazon SQS, Beanstalkd –, die Bestellverarbeitung, ERP-Synchronisation und E-Mail aus dem Request herausnimmt, sodass der Käufer nicht mehr wartet, bis die Buchhaltung antwortet. Die Dokumentation benennt auch das, was eine echte Umsetzung entscheidet: Job-Ketten und Job-Batches, eindeutige Jobs, die die Queue kein zweites Mal ausführt, Wiederholungsversuche und einen Speicher für fehlgeschlagene Jobs, aus dem sie erneut gestartet werden können. Eine doppelt ausgeführte Bestellung ist eine Rechnung, die danach jemand stornieren muss, und ein Kunde, der es früher merkt als Sie.

Horizon zeigt Durchsatz, Laufzeiten und Fehler der Queues, erlaubt es, die Worker-Konfiguration in Code zu beschreiben, und warnt, wenn eine Queue zu lange wartet – es setzt allerdings Redis voraus und arbeitet derzeit nicht mit Redis Cluster, ist also eine eigene Position auf der Hosting-Rechnung und keine kostenlose Zugabe. Transaktionen wiederum sind das, was der Satz „Bestellung und Bestandsbewegung passieren beide oder keine von beiden“ in der Praxis bedeutet: DB::transaction nimmt Änderungen im Fehlerfall selbst zurück und lässt sie wiederholen, wenn die Datenbank in einen Deadlock (wechselseitige Sperre) läuft.

Migrationen nennt die Laravel-Dokumentation Versionskontrolle für die Datenbank, und praktisch heißt das, dass Sie Tabellen, Indizes und Fremdschlüssel um Ihre eigene Preis- und Bestandslogik herum entwerfen und nicht um das, was jemand anderes einmal über den Begriff des Produkts entschieden hat. Suche und Abo-Rechnungen bleiben dabei eine Wahl und keine verpflichtende Monatszeile: Scout indexiert direkt in der Datenbank mit den Volltextindizes von MySQL oder PostgreSQL und ohne externen Dienst, und die Stripe-Seite bedient Cashier, sofern es im Shop überhaupt Abonnements gibt.

Preistabelle, Kreditlimit und Reservierung im Code

Wie das konkret aussieht, zeigt die erste der vier Zeilen am besten: Die Preistabelle für Wiederverkäufer ist auf eigenem Code eine Migration mit vier Spalten – Kundengruppe, Produkt, Mengenschwelle und Preis – und einem eindeutigen Index über die ersten drei, weshalb der Preis für einen bestimmten Käufer mit einer Abfrage und einem Join gefunden wird und nicht mit einer Suche über Meta-Werte, und eine neue Preisstufe ist eine neue Zeile in der Tabelle und keine neue Einstellung im Dialog eines fremden Herstellers. Kommt ein Jahr später eine vierte Stufe mit anderer Rundungsregel hinzu, ändern sich eine Stelle und ein Test, und beide liegen in Ihrem Repository.

Kreditlimit und Bestandsreservierung sind derselbe Gedanke einen Schritt weiter, denn auch dort hängt alles an einer Tabelle und einer Transaktion: Die Summe der offenen Rechnungen ist eine Spalte beim Kunden, und die Prüfung läuft in derselben Transaktion, in der die Bestellung entsteht, weshalb zwei gleichzeitig abgeschickte Bestellungen nicht beide unter dem Limit durchrutschen können, während sich die Transaktion im Deadlock-Fall selbst wiederholt. Die Reservierung wiederum ist eine Zeile mit Ablaufdatum, die zusammen mit der Bestellung entsteht und mit einem geplanten Hintergrundjob verschwindet, wenn die Bestellung nicht bezahlt wird – der Lagerbestand ist damit keine Zahl mehr, die zwei Käufer gleichzeitig leeren können.

Die Buchhaltungssynchronisation ist ein Queue-Job, der als eindeutig markiert ist, weshalb ein erneuter Versuch nie eine Rechnung zweimal ausstellt; und wenn Horizon am Morgen zeigt, dass es nachts auf der Buchhaltungsseite eine Unterbrechung gab, lässt der Speicher für fehlgeschlagene Jobs sie der Reihe nach noch einmal laufen, statt sie von Hand nachzutragen. Jede dieser vier Zeilen ist im fertigen Werkzeug ebenfalls zu haben, nur als Einstellungsdialog eines Herstellers, dessen Regeln Sie nicht sehen, der nach jedem Update erneut zu prüfen ist und der auf eine andere Plattform nicht mitzieht.

Zwei Projekte, die bereits laufen

Wie das im Projekt statt in der Dokumentation aussieht, zeigen unsere eigenen Laravel-Arbeiten. Auf der Bestellplattform für LIDO entscheidet nicht das Produkt über den Preis, sondern die Adresse: Die Geolokalisierung bestimmt Lieferzone, Entfernung und Gebühr, jedes der dreizehn Restaurants hat sein eigenes Speisenangebot, und neben dem Shop läuft ein eigenes System zur Prozessautomatisierung, in dem alle Bestellungen zusammenlaufen und aus dem sie auf Restaurants und Köche verteilt werden – mit Integrationen in mehr als zehn weitere Systeme, darunter Wolt, QWQER und RKeeper. Im Onlineshop von Riga Lashes auf Laravel gibt es Variantenpreise, Kundenkonten, eine Wunschliste und die Preisliste der Studioleistungen, und dahinter das Warenlager, die Anbindung der Kurierdienste und die Zahlungen, wo der Prozess bis zur Verpackung automatisiert ist. In beiden Fällen hätte man den entscheidenden Teil auch auf einem fertigen Werkzeug schreiben müssen, nur innerhalb der Preis- und Bestellformen eines fremden Herstellers, und genau das ist der Unterschied, der bleibt: Auf eigenem Code ist diese Arbeit ein Repository ohne eigenes Abo je Fähigkeit, und nach jedem Plattform-Update ist sie nicht erneut zu prüfen. Laravel schreiben wir seit 2013, und darauf laufen die meisten unserer individuellen Systeme, Portale des öffentlichen Sektors und B2B-Plattformen.

Wohin das Geld geht, das nicht in Lizenzen steckt, ist eine konkrete Frage, und die Antwort ist ebenso konkret: Die knapp 85 Stunden, die die Zeile von 848 € Jahreslizenzen in fünf Jahren kostet, sind auf eigenem Code genau diese Preistabelle, dieses Kreditlimit, diese Reservierung und diese Synchronisation, geschrieben um Ihren Prozess herum. Sie bleiben auch dann in Ihrem Repository, wenn wir irgendwann nicht mehr Ihr Partner sind: Im Auftragsbau gehört der Code vom ersten Tag an Ihnen, und das steht auch auf unserer Leistungsseite zu Laravel.

Filament: der Administrationsbereich, den niemand von Grund auf schreibt

Den Teil des Einwands, in einem selbst gebauten System müsse alles von Grund auf geschrieben werden, nimmt beim Administrationsbereich Filament weg – ein quelloffenes Oberflächen-Framework für Laravel-Anwendungen. Resources erzeugen CRUD-Masken für Eloquent-Modelle, der Table Builder liefert Filter, Sortierung und Paginierung, Formularkomponenten bringen die Validierung mit, und die Zugriffsrechte liest Filament direkt aus den Model Policies von Laravel, sodass Rollenprüfungen nicht ein zweites Mal geschrieben werden. Relation Manager, Dashboard-Widgets und Benachrichtigungen liegen ebenfalls bei; Mandantenfähigkeit auch, allerdings mit Filaments eigenem Hinweis, dass es sich um einen Werkzeugkasten und nicht um eine Garantie handelt und dass für die Datentrennung zwischen Mandanten der Umsetzende verantwortlich ist; die ganze Schicht ist MIT-lizenziert wie Laravel selbst, Lizenzgebühren fallen dort also keine an.

Wichtiger als das, was das Framework zeichnet, ist jedoch, wohin das frei gewordene Geld geht: Masken zur Produktpflege, Bestelltabellen, Filter und Rechteprüfungen sind der Teil der Entwicklung, den der Käufer nie sieht und den der Auftraggeber dennoch zum vollen Satz bezahlt; kommt er vom Framework, fließt das Budget in die Preis-, Bestell- und Lagerlogik, wegen der die individuelle Entwicklung überhaupt gewählt wurde. Ein Beispiel liegt genau dort, wo Sie das hier lesen: Diese Website läuft auf Laravel 13 und Filament 5, und die gesamte redaktionelle Arbeit in zwölf Sprachen findet in einem Bereich statt, den wir konfiguriert und nicht von Grund auf geschrieben haben.

Wo das Framework endet und der Shop beginnt

Filament ist kein Shop, und diese Grenze lohnt sich klar zu ziehen: Das Framework liefert den Administrationsbereich – Masken, Tabellen, Formulare und Rechteprüfungen –, weiß aber nichts darüber, was in diesen Tabellen steht und nach welchen Regeln es dorthin gelangt. Produktkatalog mit Varianten und Attributen, Warenkorb, Kassenschritt, Preisregeln mit Kundenstufen und Mengenrabatten, der Lebenszyklus einer Bestellung von der Anlage bis zur Retoure und die Bestandsreservierung im Lager – nichts davon liegt im Paket von Laravel und Filament. Filament ist eine fertig ausgebaute Werkstatt mit Regalen, Werkbänken und Licht; was darin produziert wird, kommt nicht mit.

Wie wörtlich das gemeint ist, zeigt die Dokumentation selbst, in der Order- und Payment-Modelle allein als Beispiele auftauchen, die der Entwickler selbst schreibt, weil es solche Klassen im Framework schlicht nicht gibt. Das ist kein Mangel des Frameworks, sondern die Arbeitsteilung: Filament verspricht eine Administrationsoberfläche und sonst nichts, genauso wie Laravel ein Framework verspricht und keine fertige Anwendung. In der Praxis heißt das, dass Filament die Arbeit an der Verwaltung verkürzt und nichts in dem Teil verkürzt, dessentwegen die individuelle Entwicklung überhaupt gewählt wurde.

Deshalb kommt in unserer Preisliste die Basic-Version eines Shops für 4.500 € ohne Lagermodul, Mehrsprachigkeit, B2B-Preisstufen, Rabattsystem und Datenmigration, die Pro-Version für 9.500 € dagegen mit allen fünf. Die Differenz ist kein Aufschlag für modernere Technik, sondern der Preis dessen, was jemand schreiben muss – und genau deshalb ist sie auf beiden Plattformen gleich. Ein Laravel-System mit festem Umfang ab 8.000 € ist in der Preisliste bereits eine andere Zeile und ein anderes Produkt: kein Shop, sondern ein System, in dem der ganze Prozess von der leeren Fläche aus entsteht.

Was wir nicht versprechen: wo individuelle Entwicklung teurer kommt

Ein selbst gebauter Shop ist frei von jährlichen Plugin-Lizenzen, nicht von Wartung, und das sind zwei völlig verschiedene Dinge. Laravel gibt jedem Release 18 Monate Fehlerkorrekturen und zwei Jahre Sicherheitskorrekturen, veröffentlicht einmal im Jahr eine neue Hauptversion und kennt keine Stufe mit verlängertem Support, weshalb die Daten konkret sind: Laravel 13 erschien am 17. März 2026 mit Sicherheitskorrekturen bis zum 17. März 2028, das Sicherheitsfenster von Laravel 11 schloss sich am 12. März 2026, und die Fehlerkorrekturen für Laravel 12 enden am 13. August 2026. Alle ein bis zwei Jahre muss das System also auf eine neue Hauptversion gehoben werden, und die Laravel-Dokumentation sagt, man bemühe sich, das an einem Tag oder schneller möglich zu machen – ein Bemühen und kein Versprechen darüber, wie lange es in Ihrem System dauert.

Die PHP-Tretmühle ist zudem für beide Seiten dieselbe: Jede Version bekommt zwei Jahre aktive Unterstützung und zwei weitere Jahre nur noch Sicherheitskorrekturen, weshalb in ein Fünfjahresfenster mindestens ein und – je nachdem, an welcher Stelle des Zyklus Sie einsteigen – bis zu zwei erzwungene PHP-Wechsel fallen, ganz gleich, was darunter liegt. Weder ein WooCommerce- noch ein Laravel-Shop entkommt dieser Zeile, und in beiden Fällen plant sie derselbe Mensch, der auch die übrige Wartung plant – der Unterschied ist allein, dass sich der Wechsel auf eigenem Code dann machen lässt, wenn es Ihnen passt, und nicht dann, wenn eine Erweiterung die alte Version nicht mehr unterstützt.

Drei Posten, bei denen das fertige Werkzeug gewinnt

Teurer als die Wartung sind drei andere Posten, und der erste davon ist das Ökosystem: Hier gewinnt das fertige Werkzeug ohne Diskussion. Eine weitere Marketing-Automatisierung ist in einem WooCommerce-Shop ein Eintrag auf dem Marktplatz – AutomateWoo etwa kostet 140 € im Jahr – und nach unserer Erfahrung ein Tagewerk, während sie im selbst gebauten System eine Spezifikation, Stunden und einen Test bedeutet, und bei 50 € pro Stunde ist sie die erste Funktion, bei der Sie fragen, ob Sie sie wirklich brauchen; ein Produktfeld oder ein neuer Filter in der Verwaltung steht nicht auf dieser Liste, denn das gibt das Framework. Das fehlende Ökosystem ist keine einmalige Ausgabe, sondern eine dauerhaft höhere Schwelle für alles, was man später ausprobieren möchte, und für einen Shop, der viel experimentiert, kann das die Lizenzrechnung aufwiegen – genau deshalb ist sie nicht unser Hauptargument.

Der zweite ist die Abhängigkeit von einem einzigen Team, und darauf antwortet die Struktur und keine Behauptung: Der Code gehört im Auftragsbau vom ersten Tag an Ihnen, wir schreiben ihn in der Standardstruktur von Laravel ohne Exotik, die kritische Logik hat Tests, und mitgeliefert werden ein dokumentiertes README und eine CI, damit ein anderes Team es übernehmen kann. Laravel-Entwickler sind in Lettland leicht zu finden, und deshalb endet unsere eigene Antwort auf die Frage, warum Laravel, mit dem Satz, dass Sie von einem einzigen Team nicht abhängig bleiben – auch nicht von uns; das Risiko hebt das nicht auf, macht es aber übertragbar.

Der dritte ist PCI DSS, und der spricht gegen uns. Die im Januar 2025 veröffentlichte und am 31. März 2025 in Kraft getretene Fassung des SAQ A hat für Händler, deren Zahlungsseite vollständig und unmittelbar von einem PCI-DSS-konformen Dienstleister ausgeliefert wird und die selbst bestätigt haben, dass die Website skriptbasierten Angriffen nicht ausgesetzt ist, die Anforderungen 6.4.3 und 11.6.1 – das Inventar der Skripte, deren Begründung und die Überwachung von Änderungen – sowie die Anforderung 12.3.1 zur gezielten Risikoanalyse gestrichen und zugleich festgehalten, dass die PCI-DSS-Anforderungen selbst damit nicht entfallen. Diese Erleichterung beschreibt einen kleinen WooCommerce-Shop mit der Zahlungsseite der Bank sehr viel genauer als einen Kassenschritt, den wir in eigenem Code abbilden, und daneben steht ein zweiter, ebenso unbequemer Umstand: Die Sicherheitslücke vom März fanden und reparierten andere, in einem System, das wir geschrieben haben, macht das unser Team – dort ist die Wartung also eine Vertragszeile und keine Annahme.

Unsere Abhängigkeiten sind nicht von anderer Art

Filament ist genau dieselbe Abhängigkeit von Dritten wie die eben besprochenen Plugins, und der Unterschied ist einer des Grades und der Platzierung, nicht des Prinzips. Es ist eine MIT-lizenzierte Abhängigkeit in der Entwicklungsschicht, ihr Code liegt in unserem Repository und lässt sich abzweigen, und sie sitzt nicht im Zahlungsweg des Käufers, weil sie den Administrationsbereich zeichnet und keine Zahlung entgegennimmt.

Bliebe das Projekt morgen stehen, nähme der Shop weiterhin Bestellungen an, und veralten würde der Teil, den Ihre Mitarbeiter sehen, nicht der, der dem Käufer Geld abnimmt. Filament veröffentlicht außerdem eine Tabelle zur Versionsunterstützung mit konkreten Daten: Die dritte Version erschien im August 2023 und erhält Sicherheitskorrekturen bis zum 1. Januar 2028 – ein längeres Fenster, als Laravel es seinen eigenen Versionen gibt.

Ein First-Party-Paket von Laravel ist Filament dennoch nicht, denn Laravel führt es in seiner eigenen Paketliste nicht auf, und hinter dem Projekt steht kein Unternehmen mit einer Bilanz, sondern ein Team um einen einzelnen Maintainer: Auf seinen Namen gehen im Repository rund 17.000 Änderungen, auf den des nächsten Mitwirkenden rund 2.400, und finanziert wird es über GitHub-Sponsoren und bezahlte Beratung. Sanft ist auch der Release-Takt nicht: Die vierte Version erschien im August 2025, die fünfte schon im Januar 2026, zwei Tage nach Livewire 4, das eine weitere Abhängigkeit von Dritten darunter ist. Und der Satz „im Bedarfsfall zweigen wir das ab“ ist billig geschrieben und teuer eingelöst.

Wir bieten keinen Shop ohne Abhängigkeiten von Dritten an, denn den haben weder wir noch sonst jemand; wir bieten weniger davon an, dazu eine Lizenz, die es erlaubt, den Code zu behalten und selbst zu pflegen, und eine klare Grenze zwischen dem, was im Ausfall den Geldfluss anhält, und dem, was den Arbeitstag Ihrer Mitarbeiter verdirbt. Wenn Ihnen dieser Unterschied nicht groß genug erscheint, ist das ein vollkommen berechtigter Einwand – und dann bauen wir Ihnen das fertige Werkzeug, denn es ist dieselbe Basic- oder Pro-Version zum selben Preis. Keine der beiden Antworten macht uns zum falschen Partner.

Wie wir diese Wahl in der Praxis treffen

Zusammen mit der Plattform kaufen Sie die Antwort auf eine einzige Frage – wer Ihre Preis- und Bestellregeln ändern darf und nach welchem Zeitplan –, und auf eigenem Code lautet diese Antwort „Sie, im nächsten Sprint“, auf der Erweiterung eines fremden Herstellers dagegen „wenn der Hersteller es in sein Release aufnimmt, falls er es aufnimmt“. Deshalb fragen wir im Erstgespräch nicht nach dem Umsatz, sondern danach, wie viele Preisstufen Sie tatsächlich haben und ob ein Kunde jemals einen anderen Preis sieht als ein anderer – das ist die Grenze zwischen den zwei Preisfeldern, die WooCommerce selbst mitbringt, und einer Preistabelle, die jemand pflegen muss.

Dann fragen wir, ob der Bestand an mehr als einem Ort lebt, denn Lager plus Ladenregal sind bereits zwei Orte, und zwei Orte heißen, dass jemand entscheiden muss, welcher von ihnen als Wahrheit gilt. Die nächsten beiden Fragen entscheiden meist alles: ob eine Bestellung sofort zur Bestellung wird oder erst eine Freigabe braucht – vom Einkauf des Kunden, von Ihrem Vertriebsleiter oder vom Kreditlimit – und ob der Prozess auch dann noch taugte, wenn der Katalog doppelt so groß wäre.

Lautet die Antwort zur Freigabe „ja“, stehen Sie an der Stelle, an der der Markt der fertigen Plugins am schwächsten ist: Die Überwachung von Kreditlimits und das Blockieren von Bestellungen über dem Limit gibt es weder im Kern noch in den verbreiteten B2B-Paketen, und versprochen wird es nur von wenigen spezialisierten Einträgen wie der QuarkCode B2B Commerce Suite. Wie viel von Ihrem Prozess Sie bereit sind, nach dem Werkzeug umzubauen – das ist die Frage, die übrig bleibt, und unklare Anforderungen sind der teuerste Fehler im ganzen Auftrag, worüber wir gesondert geschrieben haben.

Passen die Antworten in das fertige Werkzeug, nehmen Sie das fertige Werkzeug, denn es wird günstiger, und bauen werden wir es Ihnen. Passen eine oder zwei nicht hinein, sind Sie höchstwahrscheinlich auf dem mittleren Weg, und in der Preisliste entspricht dem dieselbe Pro-Version für 9.500 € auf WooCommerce – derselbe Preis wie auf Laravel, denn bezahlt wird die Arbeit und nicht die Plattform. Passen drei oder mehr nicht hinein, und besonders wenn eine Freigabestufe oder ein Kreditlimit darunter ist, geht das Gespräch nicht mehr um die Plattform, sondern darum, wie groß der Teil des Prozesses ist, der in Code lebt, den wir ohne Abstimmung mit einem fremden Hersteller ändern können.

Drei Einstiege und was jeder kostet

In der Praxis verkaufen wir drei Einstiege, und für jeden lässt sich ein Preis ausrechnen: Der erste ist, mit Katalog, Zahlungen und Versand anzufangen, live zu gehen und B2B-Preise, Rabattlogik und Lagerintegrationen erst dann zu ergänzen, wenn die ersten echten Bestellungen sichtbar sind – in unseren Antworten nennen wir das die üblicherweise richtige Wahl. Der zweite ist der Umzug eines bestehenden Shops, und das ist ein Projekt und kein Schalter: Die URL-Struktur behalten wir bei, aber die Datenmodelle decken sich nicht eins zu eins, und jedes Plugin, das eigene Felder gespeichert hat, ist gesondert zu bewerten. In der Pro-Version und in der Miete ist die Migration enthalten; in der Basic-Version nicht, und wir kalkulieren sie nach Umfang gesondert, denn den Preis entscheiden Datenmenge und Feldzahl.

Der dritte ist die Miete: ein Laravel-Shop mit unserem Hosting ab 130 € im Monat plus 600 € einmaliger Einrichtungsgebühr, und in der Preisliste ist ihr Inhalt derselbe wie bei der Pro-Version – Lagermodul, Mehrsprachigkeit, B2B-Preisstufen, Rabattsystem und Datenmigration –, nur mit Hosting, Updates und Wartung dazu; verfügbar ist sie ausschließlich mit Laravel, denn einen WooCommerce-Shop kann man bei uns nicht mieten. Die Wahl der Plattform selbst entscheidet einige konkrete Dinge, die die Arbeit nicht ausgleicht: diese Mietzeile, die kostenlosen automatischen Patches des Kerns, die Schwelle des Ökosystems und die Frage, wer zustimmen muss, bevor Ihre nächste Änderung in Produktion geht. Alles Übrige ist Arbeit.

Die Miete beginnt bei 130 € im Monat, in fünf Jahren also ab 7.800 €, plus 600 € Einrichtung – ab 8.400 € –, und darin enthalten sind Hosting, Updates und Wartung. Die Pro-Version kostet einmalig 9.500 €, und das Hosting kommt dort gesondert hinzu: Unser Infrastruktur-Hosting beginnt bei 45 € im Monat, also ab 2.700 € in fünf Jahren, zusammen ab 12.200 €, und die Updates der Anwendung stecken darin noch nicht. Beide Zahlen sind Untergrenzen und keine Endsummen, und vergleichbar sind sie deshalb, weil der Funktionsumfang beider in der Preisliste derselbe ist. In der Miete zahlen Sie für die Nutzung samt Hosting, beim Bau bezahlen Sie das System sofort, und im Vergleich der beiden Untergrenzen beginnt die Miete im Fünfjahresfenster niedriger. Wo jede von beiden endet, entscheidet der Umfang, weshalb wir beide für das Projekt kalkulieren und nicht aus der Preisliste ablesen.

Danach läuft die Arbeit in Zwei-Wochen-Sprints mit einer Demo nach jedem; Zahlungen, Versanddienstleister und Buchhaltung binden wir an und prüfen sie vor dem Start; Produkte, Kunden und Bestellhistorie übernehmen wir unter Beibehaltung der URL-Struktur. Für größere, nicht standardisierte Arbeiten arbeiten wir nach Zeit und Material mit einer Wochenobergrenze, denn ein Festpreis bedeutet dort meist entweder einen Risikoaufschlag oder Streit über den Umfang, und der Stundensatz in der Preisliste liegt bei 50 €. Der ganze Weg dauert 8–32 Wochen. Projekteinschätzung und Technologieempfehlung anfordern – beantworten Sie uns dieselben Fragen, und wir sagen Ihnen, welcher der drei Wege in Ihrem Fall weniger kostet.