Plattformeigen vor Custom: Shopify die Schwerarbeit machen lassen

Custom-Code ist leistungsfähig, erzeugt aber langfristige Betriebslast. Jeder eigene Endpoint, den ich schreibe, gehört ab dann Ihnen für immer: er muss überwacht werden, er muss bei jedem Shopify-API-Update mitgepflegt werden, und jemand, meistens ich, muss erreichbar sein, wenn er dienstags um zwei Uhr nachts ausfällt.

Deshalb prüfe ich vor jeder Zeile Go zuerst, ob Shopify die Anforderung nicht schon nativ abdeckt. Das klingt selbstverständlich, aber viele Agenturen überspringen genau diesen Schritt, weil Custom-Builds einfach mehr abrechenbare Stunden bedeuten.

Mein Standard ist das Gegenteil: Ich priorisiere native Shopify-Funktionen, Company-Accounts, Mengenstaffeln, Zahlungsziele, Metafields, Shopify Functions, Theme App Extensions, und greife erst an der Grenze zu Custom-Code, an der die Plattform tatsächlich aufhört.

So sieht diese Entscheidung in einem echten B2B-Projekt aus.

Wenn ein Kunde mir sagt, er brauche "ein individuelles Angebotssystem" oder "eine Möglichkeit, bestimmten Kunden Mengenrabatte zu geben", ist mein erster Schritt nicht der Code-Editor, sondern die Shopify-B2B-Dokumentation.

Erstaunlich viel von dem, was Kunden für Custom-Bedarf halten, deckt Shopify mit Company-Accounts, Katalogen und nativer Staffelpreislogik in Shopify Plus bereits ab. Ich habe schon vierstellige Custom-Angebote für Preislogik gesehen, die eine sauber konfigurierte Preisliste vollständig löst.

Allein dieser Schritt spart echtes Geld, auch wenn es für mich weniger abrechenbare Arbeit bedeutet. Mir ist lieber, Ihnen zu sagen "dafür brauchen Sie keinen Custom-Code", als etwas zu bauen, an dem Sie dauerhaft hängenbleiben.

Deckt die native Funktion die Anforderung nicht vollständig ab, ist der nächste Schritt Konfiguration und Erweiterungspunkte, kein eigenes Backend. Metafields tragen erstaunlich viele strukturierte Daten. Theme App Extensions fügen UI zur Storefront hinzu, ohne den Theme-Code selbst anzufassen, und überleben damit auch das nächste Redesign.

Shopify Functions sind dabei der unterschätzte Mittelweg. Sie lassen sich Checkout-Logik, Cart-Transforms und Rabattverhalten anpassen, ohne einen eigenen Service aufzusetzen. Sie laufen innerhalb der Shopify-Infrastruktur, es entsteht also kein weiterer Baustein, der ausfallen kann.

An diesem Punkt löse ich meistens schon siebzig, achtzig Prozent einer vermeintlich "individuellen" Anforderung, ganz ohne eigenständiges Backend.

Irgendwann trifft man auf etwas, das Shopify wirklich nicht kann, ein Legacy-ERP mit einem Zahlungsziel-Format, das sich nirgends nativ abbilden lässt, oder ein Logo-Upload- und Preisworkflow mit eigener Validierungslogik (genau diesen Fall habe ich in einem früheren Beitrag beschrieben). Dort verdient sich Custom-Code seinen Platz.

Auch dann halte ich den individuellen Teil so klein und isoliert wie möglich. Ein fokussierter Go-Service, der genau eine Aufgabe erledigt, mit der Shopify Admin API spricht und sich sonst raushält. Keine ausufernde Plattform, die Teile von Shopify ersetzt, die vorher schon für sich funktioniert haben.

Das Ziel ist ein System, in dem neunzig Prozent der Oberfläche weiterhin natives Shopify sind und die restlichen zehn Prozent Custom-Code an einer sauberen, klar definierten Grenze sitzen.

Wenn wir tatsächlich von einem Legacy-System oder einem aufgeblähten App-Stack wegmigrieren, mache ich keinen Big-Bang-Cutover auf einem Live-Store. Dabei kann zu viel gleichzeitig schiefgehen, und gerade B2B-Kunden können sich einen kaputten Checkout mitten im laufenden Vertriebszyklus nicht leisten.

Stattdessen läuft es in Phasen: Die neue Logik läuft parallel, wird gegen echte Bestelldaten validiert, und der Traffic wird schrittweise umgestellt. Sieht etwas komisch aus, rollen wir ein Segment zurück, nicht die gesamte Integration.

Auf dem Papier ist das langsamer. In der Praxis ist es die Version, die Sie nicht um drei Uhr nachts weckt.

Native Shopify-Funktionen vor Custom-Code zu priorisieren ist kein Selbstzweck. Es wirkt sich direkt auf das Geschäft aus:

Native Funktionen werden vom Shopify-Engineering-Team gepflegt, gegen Millionen Stores getestet und automatisch aktualisiert. Jede zusätzliche Custom-App oder jedes Skript ist ein weiterer Punkt, der beim nächsten Shopify-Update kaputtgehen kann, und den außer dem ursprünglichen Entwickler niemand wirklich versteht.

Viele Shopify-Stores, die ich übernehme, laufen mit acht oder zehn Apps, von denen sich die Hälfte überschneidet und bei denen niemand mehr weiß, wozu sie installiert wurden. Plattformeigen zuerst bedeutet weniger Abos, weniger widersprüchliche Skripte und eine Storefront, die sich tatsächlich debuggen lässt.

Custom-Code ist günstig zu schreiben und teuer, ihn dauerhaft zu warten. Bei nativen Funktionen ist es umgekehrt: die Wartung übernimmt jemand anderes. Jede Anforderung, die ich ohne eine Zeile Custom-Code löse, taucht nächstes Jahr nicht auf Ihrer Rechnung auf.