Die Frage wird oft so gestellt: “Gibt es dafür eine App?” Die Antwort ist praktisch immer ja. Der Shopify App Store beantwortet praktisch jede Anforderung, die ein Mittelständler formulieren kann, nicht selten mit einem Dutzend Kandidaten. Genau deshalb ist die Existenz einer App kein Argument.
Die nützliche Frage lautet: Was kostet uns diese Funktion über die nächsten drei Jahre, und zwar nicht nur in Euro. Jede installierte App ist ein Vertrag, ein Stück Code in Ihrer Storefront und ein Abhängigkeitsverhältnis zu einem Anbieter, dessen Fortbestand Sie nicht kontrollieren. Ein Shop mit vierzig Apps hat vierzig davon.
Dieser Artikel beschreibt, welche Optionen tatsächlich zur Wahl stehen, welche Plan-Grenzen die Entscheidung vorwegnehmen, bevor Sie überhaupt anfangen zu rechnen, und in welcher Reihenfolge Sie die Frage sinnvoll durchgehen.
Die vier Optionen, die tatsächlich zur Wahl stehen
Meist stehen zwei Optionen im Raum: App kaufen oder programmieren lassen. Tatsächlich sind es vier, und die beiden übersehenen sind oft die richtigen.
App aus dem App Store. Der Standardweg. Sie kaufen eine fertige Funktion mit laufender Gebühr und laufender Pflege durch den Anbieter.
Shopify Flow. Die kostenlose Automatisierungs-App von Shopify selbst. Ereignis, Bedingung, Aktion, ohne Code. Für alles, was aus “wenn X passiert, tue Y” besteht, ist Flow der erste Blick und nicht der letzte Ausweg.
Eigener Code. Eine Custom App, eine Theme-Anpassung oder eine Shopify Function. Einmalige Kosten, dauerhafte Verantwortung, dafür kein fremder Anbieter im Weg.
Gar nicht. Die Anforderung fallen lassen oder den Prozess so ändern, dass sie verschwindet. Das ist keine Kapitulation, sondern in einem gewachsenen Shop oft die wirtschaftlichste Antwort.
Wer nur zwischen der ersten und der dritten Option wählt, entscheidet zu teuer.
Die Plan-Grenzen, die vor der Rechnung kommen
Bevor Sie irgendetwas kalkulieren, klären Sie zwei technische Grenzen. Sie streichen Optionen ersatzlos, und sie stehen nicht im Angebot eines Dienstleisters, sondern in der Plan-Dokumentation.
Die erste betrifft Shopify Flow. Flow selbst ist kostenlos und steht auf den Plänen Basic, Grow, Advanced und Plus zur Verfügung. Die Aktion, mit der ein Workflow eine beliebige fremde Schnittstelle aufruft, also der HTTP-Request, ist aber erst ab Grow verfügbar. Auf Basic fällt damit der freie Aufruf einer fremden Schnittstelle aus; für die fertigen App-Connectoren, über die Flow an andere Dienste andockt, nennt die Dokumentation dagegen keine Plan-Grenze. Tasks, die eine Custom App eines Partners beisteuert, sind zusätzlich Plus vorbehalten; für Tasks öffentlicher Apps aus dem App Store nennt die Dokumentation keine Plan-Grenze.
Die zweite Grenze ist die härtere. Shopify Functions sind der Weg, Backend-Logik zu verändern, also Rabattlogik, Zahlungs- und Versandoptionen, Validierungen im Checkout. Apps aus dem App Store, die Functions enthalten, laufen auf allen Plänen; einzelne Function-Fähigkeiten bleiben trotzdem Plus vorbehalten. Eine eigene Function in einer Custom App setzt dagegen Shopify Plus voraus. Wer nicht auf Plus ist, kann diese Logik also nicht selbst bauen, sondern muss sie kaufen. Damit ist die Make-or-Buy-Frage für einen ganzen Bereich bereits beantwortet, bevor sie gestellt wird.
Das ist der Grund, warum “wir lassen das programmieren” bei Checkout- und Rabatt-Themen unterhalb von Plus oft ins Leere läuft. Prüfen Sie diese beiden Punkte zuerst; sie kosten ein paar Minuten und ersparen ein Angebot, das an der Plattform scheitert.
Unterhalb dieser Grenze bleibt eigener Code trotzdem möglich, nur eben nicht überall. Eine Custom App ist eine App, die ausschließlich für Ihren Shop gebaut wird. Sie ist der übliche Weg für eine Anbindung an ein Warenwirtschafts- oder Buchhaltungssystem, für einen Datenexport oder für eine Auswertung, die es so nicht zu kaufen gibt. Angelegt werden solche Apps heute über das Dev Dashboard, in Shopifys Begriffen als Custom distribution. Die ältere Variante, die direkt im Admin entstand, gibt es nur noch als Bestand aus der Zeit vor dem 1. Januar 2026; sie kann laut Shopifys Distributions-Doku keine App-Extensions tragen, also weder Flow-Tasks noch Functions. Eine Einschränkung ist erwähnenswert, weil sie beim Plan-Wechsel greift: Wer auf den Basic-Plan wechselt oder dort startet, hat keinen Zugriff auf Custom Apps mit den geschützten Kundenfeldern, bei Shopify “Custom Level 2 PII” genannt. Wer eine Anbindung plant, die Kundendaten liest, klärt das vor der Beauftragung.
Was eine App wirklich kostet
Die Monatsgebühr ist meist der kleinste und am leichtesten sichtbare Posten. Vier weitere gehören in die Rechnung, und sie sind der Grund, warum ein Shop mit vierzig Apps teurer ist als die Summe seiner Rechnungen.
Der Auswahl- und Vertragsaufwand. Jede App, die personenbezogene Daten verarbeitet, wirft die Rollenfrage auf: unter anderem Auftragsverarbeiter, eigener Verantwortlicher oder gemeinsame Verantwortlichkeit. Beantwortet ist sie erst nach einem Blick in die Bedingungen des Anbieters, und die Antworten ziehen unterschiedliche Pflichten nach sich; die Einordnung dazu steht in DSGVO und Shopify-Apps. Das ist einmalige, aber echte Arbeit, und sie fällt pro App an.
Die Storefront-Last. Apps, die im Frontend etwas ausliefern, kosten Ladezeit. Der Effekt ist bei einer App kaum messbar und wird mit jeder weiteren spürbarer.
Die Verflechtung. Je länger eine App im Shop ist, desto mehr hängt an ihr: Metafelder, Automatisierungen, Berichte, eingespielte Prozesse. Der Wechselaufwand steigt mit der Laufzeit, und zwar unabhängig davon, wie gut die App ist.
Das Anbieter-Risiko. Ein Anbieter, der eine App nicht mehr weiterentwickelt, ist ein Posten mit offenem Ende. Wie schnell das konkret wird, zeigt der Script-Tag-Fahrplan: Ab dem 1. Oktober 2026 lassen sich keine neuen Script-Tags mehr anlegen, ab dem 1. März 2027 liefert Shopify vorhandene nicht mehr aus. Apps, die ihre Funktion über diese alte Technik ausliefern und bis dahin nicht umgestellt werden, hören dann ohne Fehlermeldung auf zu arbeiten. Wir haben die beiden Termine im Beitrag dazu getrennt.
Keiner dieser Posten spricht grundsätzlich gegen Apps. Sie sprechen dagegen, eine App zu installieren, ohne die Frage gestellt zu haben.
Wann Flow reicht
Flow wird unterschätzt, weil es unspektakulär aussieht. Für eine große Klasse von Anforderungen ist es trotzdem die richtige Antwort, und zwar immer dann, wenn die Anforderung sich als Reaktion auf ein Ereignis im Shop formulieren lässt.
Typische Fälle: Bestellungen ab einem Schwellenwert taggen, Kunden nach Verhalten in Segmente einsortieren, bei Lagerbestand unter einer Grenze eine Benachrichtigung auslösen, Risiko-Bestellungen zur manuellen Prüfung markieren, nach dem Kauf ein Ereignis an ein anderes System schicken. Für all das braucht es keine App und keinen Entwickler.
Die Grenze von Flow liegt dort, wo es keine Reaktion auf ein Ereignis mehr ist, sondern eine eigene Oberfläche, eine eigene Datenhaltung oder eine Logik mitten im Kaufprozess. Flow ändert nicht, was im Checkout passiert; es reagiert darauf, dass etwas passiert ist. Wer diesen Unterschied kennt, spart sich die meisten Fehlversuche.
Wann Kaufen die richtige Antwort ist
Eine gekaufte App ist die richtige Wahl, wenn die Funktion nicht Ihr Geschäft ist und der Anbieter sie besser pflegt, als Sie es täten.
| Wahl | Wann sie passt | Typische Anzeichen |
|---|---|---|
| Kaufen | Die Funktion ist Standardbedarf und nicht Ihr Unterscheidungsmerkmal | Problem vieler Shops; Anbieter pflegt aktiv und dokumentiert; regulatorisch getrieben und laufend zu aktualisieren; Wechsel wäre in überschaubarer Zeit machbar |
| Erst Flow prüfen | Die Anforderung lässt sich als Ereignis und Reaktion formulieren | Tagging, Segmentierung, Benachrichtigung; Anbindung an ein System mit Schnittstelle; kein eigenes Interface nötig |
| Selbst bauen | Die Logik gehört Ihnen, oder es gibt nur Umwege | Differenzierungsmerkmal; drei Apps ersetzen eine Funktion; Datenfluss soll im Haus bleiben; der Plan erlaubt es technisch |
Der klarste Kauf-Fall sind Anforderungen, die sich von außen ändern. Alles, was regulatorisch getrieben ist, veraltet ständig, und ein Anbieter, der das für viele Shops nachzieht, ist günstiger als jede eigene Lösung. Der zweite klare Kauf-Fall sind Funktionen, die austauschbar sind: Wenn ein Wechsel des Anbieters in überschaubarer Zeit machbar wäre, ist das Anbieter-Risiko klein und der Kauf unkritisch.
Wann eigener Code sich rechnet
Eigener Code lohnt sich in drei Situationen, und in keiner davon geht es primär um Geld.
Erstens, wenn die Logik Ihr Unterscheidungsmerkmal ist. Eine eigene Kalkulation, eine besondere Konfiguration, eine Regel, die aus Ihrem Sortiment folgt: Was Sie von Wettbewerbern unterscheidet, sollten Sie nicht von einem Anbieter mieten, der es allen anbietet.
Zweitens, wenn die App-Landschaft nur Umwege hergibt. Wenn eine Anforderung drei Apps braucht, die sich gegenseitig Daten zuschieben, ist das kein Kauf mehr, sondern ein Integrationsprojekt mit drei Vertragspartnern. Eine Custom App ist dann häufig die schlichtere Lösung, auch wenn sie in der ersten Rechnung teurer aussieht.
Drittens, wenn der Datenfluss nicht nach außen soll. Jede App, die Bestell- oder Kundendaten verarbeitet, verlängert die Kette. Manchmal ist der Verzicht auf diese Verlängerung das eigentliche Argument, und er ist bei einer Custom App, die nur Ihren Shop bedient, leichter zu führen.
Was gegen eigenen Code spricht, ist nicht die Entwicklung, sondern der Betrieb. Wer selbst baut, übernimmt die Pflege auf Dauer, inklusive der Anpassung an Shopifys eigene Änderungen. Diese Pflege ist der Posten, der in Angeboten fehlt und in der Realität anfällt.
Die Option, die am häufigsten übersehen wird
Bevor Sie eine der drei technischen Optionen wählen, lohnt eine Runde mit der vierten. Viele Anforderungen entstehen nicht aus dem Geschäft, sondern aus einem Prozess, den einmal jemand so eingerichtet hat.
Die nützliche Gegenfrage lautet: Was passiert, wenn wir es nicht tun? Bei einer Funktion, die zweimal im Jahr gebraucht wird, ist die Antwort oft “wir machen es dann von Hand”, und das ist billiger als jede Automatisierung. Bei einer Funktion, die einen Bericht erzeugt, den niemand liest, ist die Antwort “nichts”.
Das klingt banal und ist oft der größere Hebel als jede der drei technischen Optionen. Ein App-Stack wächst durch Addition; er schrumpft nur, wenn jemand die Frage stellt.
Der Ausstieg gehört zur Entscheidung
Der Teil, der bei der Auswahl praktisch nie besprochen wird, ist der Abschied. Dabei entscheidet er, wie teuer ein Fehlgriff wird.
Zwei Dinge sollten Sie vor der Installation wissen. Erstens: Was passiert mit den Daten, die diese App im Shop angelegt hat? Metafeld-Definitionen in einem app-eigenen Namensraum löscht Shopify bei der Deinstallation; die Werte behält es zunächst ohne Definition und sagt ausdrücklich keine Frist für das Aufräumen zu. Bestell-, Kunden- und Produkt-Tags sowie Metafelder in einem frei gewählten Namensraum bleiben dagegen im Shop stehen, und zwar so lange, bis jemand sie entfernt. Zweitens: Was passiert mit Ihren Daten beim Anbieter? Shopify verpflichtet Apps aus dem App Store auf einen festen Ablauf und sendet dem Anbieter 48 Stunden nach der Deinstallation eine Aufforderung, die Daten des Shops zu löschen. Dass diese Aufforderung ergeht, ist geregelt; dass ein Anbieter sie sauber umsetzt, gehört in die Auswahl.
Ein praktischer Zusatz, der Zeit spart: Notieren Sie bei jeder Installation in einem Satz, wofür die App da ist und wer sie wollte. In zwei Jahren ist das die einzige Information, die fehlt, wenn jemand ausmisten will.
Die Reihenfolge, die wir empfehlen
Fünf Fragen, in dieser Reihenfolge. Erstens: Brauchen wir das überhaupt, und was passiert, wenn wir es lassen? Zweitens: Lässt sich die Anforderung als Ereignis und Reaktion formulieren, also mit Flow lösen? Drittens: Erlaubt unser Plan die Option, die wir uns vorstellen, insbesondere bei Checkout- und Rabattlogik? Viertens: Ist das unser Unterscheidungsmerkmal oder Standardbedarf? Fünftens: Wie sähe der Ausstieg aus?
Wer diese fünf Fragen beantwortet, hat in aller Regel keine Entscheidung mehr zu treffen, sondern nur noch aufzuschreiben. Unsere eigene Marke Vaultskin betreiben wir seit der Migration von Magento 2 auf Shopify Plus über vierzehn Länder; die Frage, ob eine Anforderung eine App, einen Workflow oder eigenen Code verlangt, stellt sich dort laufend neu, und sie endet seltener bei einer Custom App, als man beim Lesen des App Stores vermuten würde.
Wenn Sie einen gewachsenen App-Stack haben und wissen wollen, was davon bleiben sollte, ist eine Inventur der erste Schritt; die datenschutzrechtliche Seite davon steht in DSGVO und Shopify-Apps. Für den umgekehrten Fall, also eine konkrete Anforderung ohne passende App, sortieren wir die vier Optionen mit Ihnen im Rahmen von Setup und Migration; wenn es um Automatisierung rund um E-Mail und Kundendaten geht, gehört das eher zu Marketing-Flows. Schildern Sie uns über das Kontaktformular, welche Anforderung ansteht und auf welchem Plan Sie sind, dann sagen wir Ihnen, welche der vier Optionen bei Ihnen überhaupt offensteht.