Shopify AutomatisierungCustom AppsERP-IntegrationShopify API

Shopify Custom-Automatisierung: Wann Plugins versagen

Wann stoßen Shopify-Apps und Flow an ihre Grenzen? Ich zeige 8 kritische Prozesse, die nur Custom-Code löst — mit echten Zahlen, API-Beispielen und ROI-Kalkulation für 2026.

Justin KreutzmannJustin Kreutzmann14 min Lesezeit

Mittelgroße Shopify-Shops verlieren laut einer Bitvea-Analyse durchschnittlich 40 % ihrer Betriebszeit an repetitive Aufgaben, die längst automatisiert sein könnten. Zehn installierte Apps, drei Zapier-Zaps, Shopify Flow bis zum Anschlag ausgebaut — und trotzdem sitzt jemand jeden Morgen zwei Stunden vor Excel und tippt Bestandsdaten ab.

Das Problem liegt nicht bei den Tools. Es liegt daran, dass Standard-Plugins für Standard-Probleme gebaut werden. Sobald Ihr Shop komplexe Lagerlogik, ERP-Anbindungen oder unternehmensweite Preisregeln hat, reichen vorgefertigte Lösungen strukturell nicht mehr aus.

In diesem Artikel zeige ich Ihnen acht konkrete Prozesse, bei denen ich in Kundenprojekten auf genau diese Wand gestoßen bin — und wie Custom-Automatisierung diese Lücken schließt. Mit aktuellem Code, echten ROI-Zahlen und einer klaren Entscheidungshilfe, wann sich der Aufwand lohnt.

Das Wichtigste in Kürze

  • 40 % der Betriebszeit gehen in Shopify-Shops durchschnittlich an manuelle, automatisierbare Aufgaben verloren.
  • Standard-Apps haben drei strukturelle Limits: One-size-fits-all-Logik, geteilte API-Kontingente und kein System-übergreifendes Denken.
  • Plugin-Stacking ab 4–5 zusammenhängenden Apps kostet oft mehr als eine Custom-Lösung — und bleibt trotzdem lückenhaft.
  • Shopify Flow nutzt seit Januar 2026 die GraphQL Admin API 2026-01 mit erweiterten Metafield-Abfragen und Bulk-Mutations.
  • Custom-Automatisierung amortisiert sich bei 300 €+/Monat laufenden App-Kosten typischerweise in 12–18 Monaten.
  • Acht Prozesse in diesem Artikel — von Multi-Warehouse-Sync bis Compliance-Prüfung — lassen sich nur mit eigenem Code zuverlässig lösen.

Warum Standard-Plugins strukturell scheitern

Bevor wir in die konkreten Prozesse einsteigen, lohnt sich ein kurzer Blick auf die Wurzel des Problems — denn das ist kein Qualitätsproblem einzelner Apps.

Die drei fundamentalen Limitierungen

LimitierungTechnische UrsacheKonsequenz
One-size-fits-allApps müssen für Tausende Shops funktionierenIhre spezifische Businesslogik passt nicht rein
Geteilte API-KontingenteJede installierte App verbraucht Ihr Shopify-API-BudgetBei vielen Apps: Race-Conditions und Sync-Fehler
Shopify-only-DenkenPlugins kennen nur Shopify-DatenERP, PIM, WMS, CRM bleiben außen vor

Die versteckten Kosten des Plugin-Stacking

Ein typischer Stack, den ich bei Bestandskunden sehe:

Bestandsmanagement-App:    49 $/Monat
Pricing-App:               79 $/Monat
Fulfillment-App:           39 $/Monat
B2B-App:                   99 $/Monat
Returns-App:               59 $/Monat
Sync-App:                  29 $/Monat
─────────────────────────────────────
Gesamt:                   354 $/Monat = 4.248 $/Jahr

Fast 4.300 $ pro Jahr — und trotzdem bleiben Lücken, weil jede App ihr eigenes Datenmodell mitbringt. Wenn dann zwei Apps denselben Webhook abfangen, beginnt das Chaos.

40 %
Betriebszeit durch manuelle Aufgaben verlorenQuelle: Bitvea, 2025
20+ h
Ersparnis pro Woche durch richtige AutomatisierungQuelle: Shopify Enterprise Blog, 2025
248 %
3-Jahres-ROI bei Workflow-AutomatisierungQuelle: Forrester / Microsoft, 2024

Prozess 1: Multi-Warehouse-Bestandsabgleich mit verschiedenen ERP-Systemen

Das Problem

Sie betreiben drei Lager: Deutschland (SAP), Polen (eigenes WMS), Dropshipper (CSV per SFTP). Jedes System hat andere Update-Zyklen, andere Protokolle, andere Datenformate. Overstock in einem Lager, während ein anderes Stockout meldet.

Warum Apps scheitern

Standard-Inventory-Apps wie Stocky oder Katana unterstützen eine Datenquelle. Multi-ERP-Setups mit REST, SOAP und SFTP parallel kennen sie nicht. Auch Priorisierungslogik — welches Lager bei Bestelleingang zuerst bedient wird — ist nicht vorgesehen.

Die Custom-Lösung

services/inventory-sync.js
// Zentraler Bestandsabgleich — läuft alle 15 Minuten via Cron
async function syncInventoryFromAllSources() {
  const [sapStock, wmsStock, dropshipStock] = await Promise.all([
    fetchSAPInventory({ warehouse: 'DE-MAIN', apiVersion: '2026-01' }),
    fetchWMSInventory({ protocol: 'soap', warehouse: 'PL-FULFILLMENT' }),
    fetchDropshipCSV({ sftp: process.env.SFTP_HOST, path: '/exports/stock_daily.csv' }),
  ]);
 
  // Priorisierte Zusammenführung: DE > PL > Dropship
  const mergedInventory = mergeWithPriority([
    { source: sapStock,      priority: 1, locationId: 'gid://shopify/Location/1001' },
    { source: wmsStock,      priority: 2, locationId: 'gid://shopify/Location/1002' },
    { source: dropshipStock, priority: 3, locationId: 'gid://shopify/Location/1003' },
  ]);
 
  // Shopify Admin API 2026-01: Bulk-Inventory-Update mit Idempotency-Keys
  await shopify.graphql(`
    mutation inventorySetQuantities($input: InventorySetQuantitiesInput!) {
      inventorySetQuantities(input: $input) {
        inventoryAdjustmentGroup { reason }
        userErrors { field message }
      }
    }
  `, { input: { reason: 'correction', quantities: mergedInventory, ignoreCompareQuantity: true } });
}

Ergebnis aus einem Kundenprojekt: 3 Stunden tägliche Bestandspflege entfallen, Überverkäufe um 94 % reduziert, Amortisierung innerhalb von 8 Wochen.

Prozess 2: Dynamische Preisanpassung mit Margen-Schutz

Das Problem

2.000 Produkte, 100 preissensible Top-Artikel, die Wettbewerber täglich ändern. Das Ziel: immer 2–5 % unter dem günstigsten Wettbewerber — aber nur wenn die Marge über 15 % bleibt. Premium-Marken werden ausgenommen, außerhalb der Geschäftszeiten keine Änderungen.

Warum Apps scheitern

Repricing-Tools wie Prisync arbeiten mit festen Prozentsätzen. Mehrstufige Bedingungslogik (Marge + Wettbewerber + Markenausnahme + Tageszeit + Lagerbestand) übersteigt ihr Regelwerk. Eine direkte Anbindung an Ihren ERP-Einkaufspreis? Fehlanzeige.

Die Custom-Lösung

services/repricing.js
async function adjustPrices() {
  const [products, competitors, margins] = await Promise.all([
    getCompetitiveProducts(),      // Top-100 aus Shopify
    scrapeCompetitorPrices(),      // Eigene Crawling-Pipeline
    getMarginDataFromERP(),        // Einkaufspreise aus SAP/Sage
  ]);
 
  for (const product of products) {
    const comp   = competitors[product.sku];
    const margin = margins[product.sku];
    if (!comp || !margin || product.vendor === 'PremiumBrand') continue;
 
    const targetPrice = comp.lowestPrice * 0.97; // 3 % darunter
    const effectiveMargin = (targetPrice - margin.purchasePrice) / targetPrice;
 
    // Mindestmarge 15 % einhalten
    const finalPrice = effectiveMargin < 0.15
      ? margin.purchasePrice / 0.85
      : targetPrice;
 
    await shopify.graphql(`
      mutation productVariantUpdate($input: ProductVariantInput!) {
        productVariantUpdate(input: $input) {
          productVariant { id price }
          userErrors { field message }
        }
      }
    `, { input: { id: product.variantGid, price: roundToNine(finalPrice).toString() } });
  }
}
 
const roundToNine = (price) => (Math.floor(price) + 0.99);

Ergebnis: +3,2 % Gesamtumsatz bei gleichbleibender Marge, 4 Stunden/Woche manuelle Preisprüfung entfallen.

Prozess 3: Custom Fulfillment-Routing nach Produkttyp und Gewicht

Das Problem

Eine Bestellung, drei Zeilen: Sperrgut (Spedition), zwei Normalpakete (DHL), digitales Produkt (Sofort-Download). Die Bestellung soll automatisch aufgeteilt, an verschiedene Carrier übergeben und dem Kunden als eine einheitliche Sendungsverfolgung präsentiert werden.

Warum Apps scheitern

ShipStation und Sendcloud beherrschen Multi-Carrier-Versand. Die automatische Aufteilung einer Bestellung nach Produkteigenschaften — Typ, Gewicht, Gefahrgut-Status, Lager-Zuweisung — in verschiedene Fulfillments inklusive Speditionslogik liegt außerhalb ihres Funktionsumfangs.

Die Custom-Lösung

services/fulfillment-router.js
const ROUTES = {
  SPERRGUT: { carrier: 'spedition_api',  locationId: 'LOC_WAREHOUSE_DE' },
  STANDARD: { carrier: 'dhl_api',        locationId: 'LOC_WAREHOUSE_DE' },
  DIGITAL:  { carrier: null,             locationId: null },
  DROPSHIP: { carrier: 'supplier_api',   locationId: 'LOC_SUPPLIER' },
};
 
function classifyProduct(lineItem) {
  if (!lineItem.requiresShipping)         return 'DIGITAL';
  if (lineItem.grams > 31_500)            return 'SPERRGUT'; // > 31,5 kg
  if (lineItem.vendor === 'DropShipCo')   return 'DROPSHIP';
  return 'STANDARD';
}
 
async function routeOrderFulfillment(order) {
  const grouped = {};
  for (const item of order.lineItems) {
    const cat = classifyProduct(item);
    (grouped[cat] ??= []).push(item);
  }
 
  for (const [category, items] of Object.entries(grouped)) {
    if (category === 'DIGITAL') {
      await fulfillDigitalItems(order.id, items);
      continue;
    }
    const route = ROUTES[category];
    const fulfillment = await createFulfillmentOrder({ orderId: order.id, items, locationId: route.locationId });
    await submitToCarrier(route.carrier, fulfillment);
  }
}

Ergebnis: Bei 50 Mixed-Bestellungen/Tag = 6,6 Stunden Zeitersparnis täglich (vorher 8 Min. pro Bestellung manuell).

Prozess 4: PIM-zu-Shopify Metafield-Sync mit Transformation

Das Problem

Produktdaten leben in Akeneo oder Pimcore: technische Spezifikationen, Pflegehinweise, CE-Kennzeichnungen, Zertifizierungen. Diese müssen als Metafields strukturiert, validiert und in der richtigen Sprache in Shopify landen.

Warum Apps scheitern

Akeneo-Konnektoren synchronisieren Basisdaten. Aber komplexes Mapping (ein PIM-Feld → mehrere Shopify-Metafields mit Transformation), bedingte Generierung (Metafield X nur wenn Produkttyp = Textil) und Validierung gegen externe Schemas gehen über Plugin-Fähigkeiten hinaus.

Die Custom-Lösung

services/pim-sync.js
// Shopify Admin API 2026-01: Metafields in einer Batch-Mutation setzen
async function syncMetafieldsFromPIM(pimProduct, shopifyGid) {
  const metafields = [];
 
  // Basis: für alle Produkte
  metafields.push({ ownerId: shopifyGid, namespace: 'specs', key: 'material',
    type: 'single_line_text_field', value: pimProduct.attributes.material?.de ?? '' });
 
  // Konditional: Nur für Textilien (Textile Labelling Regulation EU 1007/2011)
  if (pimProduct.category === 'textiles') {
    metafields.push({ ownerId: shopifyGid, namespace: 'specs', key: 'textile_composition',
      type: 'single_line_text_field',
      value: formatTextileComposition(pimProduct.attributes.composition) });
  }
 
  // Zertifizierungen als strukturierte Liste
  if (pimProduct.certifications?.length) {
    metafields.push({ ownerId: shopifyGid, namespace: 'compliance', key: 'certifications',
      type: 'list.single_line_text_field',
      value: JSON.stringify(pimProduct.certifications.map(c => c.name)) });
  }
 
  await shopify.graphql(`
    mutation metafieldsSet($metafields: [MetafieldsSetInput!]!) {
      metafieldsSet(metafields: $metafields) {
        metafields { key namespace value }
        userErrors { field message }
      }
    }
  `, { metafields });
}

Ergebnis: 312 Arbeitsstunden/Jahr eingespart, Fehlerrate von 12 % auf 0,3 % gesenkt.

Prozess 5: Cross-Store-Synchronisation im Multi-Brand-Betrieb

Das Problem

Drei Shopify-Stores, verschiedene Marken, ein gemeinsamer Bestandspool. Produkte existieren in allen Stores mit unterschiedlichen Preisen und Beschreibungen. Bestellungen sollen in einem zentralen Dashboard konsolidiert und gemeinsam gefulfilled werden.

Warum Apps scheitern

Syncio kann Produkte kopieren — aber keine selektive Synchronisation (nur bestimmte Felder, unterschiedliche Preise pro Store), keine konsolidierte Bestandslogik mit Store-Priorisierung und kein einheitliches Order-Management.

Die Custom-Lösung

services/cross-store-sync.js
const STORES = [
  { name: 'Brand A', priority: 1, reserveStock: 5,  client: shopifyClientA },
  { name: 'Brand B', priority: 2, reserveStock: 3,  client: shopifyClientB },
  { name: 'Brand C', priority: 3, reserveStock: 0,  client: shopifyClientC },
];
 
async function crossStoreInventorySync() {
  const centralStock = await getCentralInventoryFromERP();
 
  for (const sku of Object.keys(centralStock)) {
    let remaining = centralStock[sku].quantity;
 
    for (const store of STORES) {
      const mapping = await getProductMapping(store.name, sku);
      if (!mapping) continue;
 
      const allocated = Math.max(0, remaining - store.reserveStock);
      remaining -= allocated;
 
      // Shopify Inventory API mit Idempotency-Key (neu in 2026-01)
      await store.client.graphql(`
        mutation inventorySetQuantities($input: InventorySetQuantitiesInput!) {
          inventorySetQuantities(input: $input) {
            userErrors { field message }
          }
        }
      `, { input: {
        reason: 'correction',
        quantities: [{ inventoryItemId: mapping.inventoryItemId,
                       locationId: mapping.locationId, quantity: allocated }],
      }});
    }
  }
}

Ergebnis: 40 % weniger Operations-Aufwand, Überverkäufe eliminiert, 15 % weniger entgangener Umsatz durch Stockouts.

Prozess 6: Automatisierte B2B-Preislogik mit ERP-Vertragsanbindung

Das Problem

200 B2B-Kunden mit individuellen Strukturen: Kunde A bekommt 25 % auf Kategorie X, aber 10 % auf Y. Kunde B hat Festpreise für seine Top-50-Artikel. Kunde C erhält gestaffelte Mengenrabatte ab 100 Stück. All das soll live mit Shopify B2B und den Preis-Katalogen zusammenarbeiten.

Warum Apps scheitern

Shopify B2B bietet Preis-Kataloge — aber statisch. Dynamische Staffelpreise, kombinierte Regeln (Menge + Kundenstatus + Saison) und automatische Preisübertragung aus ERP-Verträgen gehen darüber hinaus.

Die Custom-Lösung

services/b2b-pricing.js
async function calculateB2BPrice(companyId, variantId, quantity) {
  const [contract, variant] = await Promise.all([
    getB2BContract(companyId),   // Aus ERP geladen
    getVariant(variantId),
  ]);
  let price = parseFloat(variant.price);
  const rules = [];
 
  // Stufe 1: Kategorierabatt
  const catDiscount = contract.categoryDiscounts?.[variant.productType];
  if (catDiscount) { price *= (1 - catDiscount / 100); rules.push(`Kat. -${catDiscount}%`); }
 
  // Stufe 2: Festpreise überschreiben
  if (contract.fixedPrices?.[variant.sku]) {
    price = contract.fixedPrices[variant.sku];
    rules.splice(0, rules.length, `Festpreis ${price} €`);
  }
 
  // Stufe 3: Mengenstaffel
  const tier = contract.volumeTiers
    ?.sort((a, b) => b.minQty - a.minQty)
    .find(t => quantity >= t.minQty);
  if (tier) { price *= (1 - tier.discount / 100); rules.push(`Menge -${tier.discount}%`); }
 
  return { originalPrice: parseFloat(variant.price), finalPrice: Math.round(price * 100) / 100, rules };
}

Ergebnis: 60 % weniger Pricing-Fehler, 3× schnellere Angebotserstellung, 1 Tag/Woche Verwaltungsaufwand entfällt.

Prozess 7: Orchestrierte Order-Workflows mit Fehlerbehandlung

Das Problem

Bestellung eingehend → Betrugsprüfung → parallel: Rechnung + Fulfillment + CRM-Update → wenn B2B: Lieferschein mit Custom-Template → nach Versand: Tracking-Seite mit Upsells personalisieren. Und wenn ein Schritt fehlschlägt, darf das nicht den gesamten Workflow korrumpieren.

Warum Apps scheitern

Shopify Flow beherrscht einfache Wenn-Dann-Ketten. Parallele Ausführung, Fehlerbehandlung mit Retry-Logik, bedingte Verzweigungen über externe Systeme und transaktionale Sicherheit (Rollback bei Teilfehler) sind in Flow nicht abbildbar.

Die Custom-Lösung

services/order-orchestrator.js
class OrderWorkflowOrchestrator {
  async handleNewOrder(order) {
    const fraudCheck = await this.checkFraud(order);
 
    if (fraudCheck.risk === 'high') {
      await Promise.all([this.holdOrder(order.id), this.notifySupport(order)]);
      return;
    }
 
    // Parallele Verarbeitung — Promise.allSettled verhindert Cascade-Fehler
    const results = await Promise.allSettled([
      this.generateInvoice(order),
      this.initiateFulfillment(order),
      this.updateCRM(order),
    ]);
 
    // Fehler einzelner Schritte: Retry mit Exponential Backoff
    for (const [i, res] of results.entries()) {
      if (res.status === 'rejected') await this.scheduleRetry(i, order.id);
    }
 
    if (order.customer?.tags?.includes('b2b')) {
      await this.generateCustomDeliveryNote(order);
    }
  }
 
  async scheduleRetry(stepIndex, orderId, attempt = 1) {
    const delay = Math.min(1_000 * 2 ** attempt, 60_000); // max 60 s
    setTimeout(async () => {
      try { await this.retryStep(stepIndex, orderId); }
      catch (e) { attempt < 5
        ? this.scheduleRetry(stepIndex, orderId, attempt + 1)
        : this.escalateToSupport(stepIndex, orderId); }
    }, delay);
  }
}

Ergebnis: Verarbeitungsquote 99,7 % (vorher 91 %), 4 Apps eingespart.

Prozess 8: Automatisierte Compliance-Prüfung (GPSR, WEEE, VerpackG)

Das Problem

Als Shopify-Händler in Deutschland greifen mehrere Regelwerke gleichzeitig: GPSR (General Product Safety Regulation, seit Dezember 2024 Pflicht), WEEE für Elektrogeräte, VerpackG, CE-Kennzeichnung, Textilkennzeichnung. Bei 500+ Produkten aus verschiedenen Quellen ist manuelle Prüfung ein Vollzeitjob.

Warum Apps scheitern

Es gibt schlicht keine Standard-Plugins für deutsche E-Commerce-Compliance. Die Anforderungen sind zu spezifisch, zu dynamisch und zu stark von Produktkategorie und Lieferkette abhängig. Internationale App-Entwickler bauen keine Apps für das Verpackungsgesetz.

Die Custom-Lösung

services/compliance-checker.js
async function runComplianceCheck() {
  const products = await getAllActiveProducts();
  const issues = [];
 
  for (const product of products) {
    const productIssues = [];
 
    // GPSR: Seit 13.12.2024 EU-Pflicht — verantwortliche Person angeben
    if (!product.metafields?.compliance?.gpsr_responsible) {
      productIssues.push({ severity: 'critical', type: 'GPSR',
        message: 'Verantwortliche Person nach GPSR fehlt' });
    }
 
    // WEEE: Elektrogeräte brauchen stiftung ear Registrierung
    if (isElectrical(product) && !product.metafields?.compliance?.weee_number) {
      productIssues.push({ severity: 'critical', type: 'WEEE',
        message: 'WEEE-Registrierungsnummer fehlt (Bußgeld bis 100.000 €)' });
    }
 
    // VerpackG: Lizenzierung bei LUCID für alle physischen Produkte
    if (product.requiresShipping && !product.metafields?.compliance?.verpackg_licensed) {
      productIssues.push({ severity: 'warning', type: 'VerpackG',
        message: 'Verpackungslizenz bei LUCID nicht nachgewiesen' });
    }
 
    if (productIssues.length) {
      issues.push({ product: product.title, issues: productIssues });
      await tagProduct(product.id, productIssues.map(i => `compliance:${i.type}:missing`));
    }
  }
 
  await sendReportEmail(generateComplianceReport(issues));
  return issues;
}
SchweregradTypKonsequenz ohne Prüfung
KritischGPSRAbmahnrisiko, Produktsperrung
KritischWEEEBußgeld bis 100.000 €
WarnungVerpackGBußgeld bis 200.000 €
KritischCEMarktverbot innerhalb der EU

Ergebnis: Wöchentlicher automatischer Audit, sofortige Benachrichtigung bei neuen Produkten, Compliance-Risiken systematisch sichtbar gemacht.

Wann lohnt sich Custom-Automatisierung wirklich?

Custom lohnt sich, wenn...

  • Mehr als 300 €/Monat für Automatisierungs-Apps ausgegeben werden
  • Regelmäßige manuelle Workarounds für Plugin-Limitierungen nötig sind
  • Prozesse mehrere externe Systeme einbeziehen (ERP, PIM, WMS)
  • Spezifische deutsche Compliance-Anforderungen gelten
  • Multi-Store oder Multi-Brand-Betrieb vorliegt
  • B2B-Preislogik zu komplex für Standard-Kataloge ist
  • Mehr als 500 Bestellungen/Monat verarbeitet werden

Standard-Apps reichen, wenn...

  • Einzelner Store mit Standardprozessen betrieben wird
  • Fulfillment: ein Lager, ein Carrier
  • Unter 200 Bestellungen/Monat
  • Preis- und Rabattlogik einfach und einheitlich ist
  • Keine ERP-Integration benötigt wird
  • Shopify Flow und 1–2 spezialisierte Apps ausreichen

Die Break-Even-Formel

Monatliche Einsparung = manuelle Arbeitsstunden × Stundensatz
                      + entfallende App-Kosten
                      + vermiedene Fehlerkosten
 
Break-Even (Monate) = Entwicklungskosten ÷ Monatliche Einsparung

Konkretes Beispiel: 2 Mitarbeiter à 5 h/Monat manuell (350 €) + 3 Apps à 50 € (150 €) + 2 Fehler/Monat (70 €) = 570 €/Monat Einsparung. Bei 5.000 € Entwicklungskosten: Break-Even nach 9 Monaten, danach 570 € netto monatlich gespart.

Fazit: Automatisierung ist kein Plugin-Problem

Die meisten Shopify-Händler starten richtig: Apps für Standardaufgaben, Flow für einfache Wenn-Dann-Logik. Aber ab einem gewissen Wachstumspunkt werden die Lücken zwischen den Apps größer als die Funktionalität der Apps selbst.

Custom-Automatisierung ist kein Luxus — es ist die logische nächste Stufe für Shops, die skalieren wollen, ohne proportional mehr Personal für repetitive Prozesse einzustellen. Die acht Prozesse in diesem Artikel sind keine theoretischen Szenarien, sondern genau die Herausforderungen, die mir Händler regelmäßig schildern.

Wenn Sie sich in zwei oder mehr dieser Szenarien wiederfinden: Der richtige Zeitpunkt ist meistens früher, als Sie denken.

Häufige Fragen

Ab wann lohnt sich Custom-Automatisierung für Shopify?

Als Faustregel: Wenn Sie mehr als 300–400 € monatlich für Automatisierungs-Apps ausgeben oder wenn Ihr Team regelmäßig manuelle Zwischenschritte für Prozesse übernimmt, die "eigentlich automatisch laufen sollten". Bei 500+ Bestellungen/Monat und ERP-Anbindung ist Custom fast immer die wirtschaftlichere Wahl.

Was kostet Custom-Automatisierung für Shopify?

Einfache Middleware-Lösungen beginnen bei 2.000–5.000 € Entwicklungskosten, komplexe Multi-System-Integrationen bei 10.000–25.000 €. Hosting kostet 5–50 €/Monat. Der Break-Even liegt bei typischen Projekten zwischen 9 und 18 Monaten — danach sparen Sie dauerhaft Monat für Monat.

Kann ich Custom-Automatisierung mit Shopify Flow kombinieren?

Ja — und das ist oft die klügste Strategie. Flow übernimmt einfache interne Automatisierungen (Tags setzen, Benachrichtigungen), Custom-Middleware die systemübergreifenden, geschäftskritischen Workflows. Beide können zusammenarbeiten: Flow setzt einen Tag, die Middleware reagiert darauf.

Welche Shopify API-Version sollte für neue Automatisierungen genutzt werden?

Seit Januar 2026 ist die GraphQL Admin API Version 2026-01 aktuell. Sie bringt u. a. verbesserte Bulk-Operations, Idempotency-Keys für Inventory-Mutations und erweiterte Metafield-Abfragen. Alle neuen Projekte sollten diese Version einsetzen. Shopify unterstützt API-Versionen 24 Monate lang.

Brauche ich für Custom-Automatisierung eine Shopify Plus-Lizenz?

Nein. Custom Apps und Middleware-Lösungen funktionieren auf allen Shopify-Plänen. Shopify Plus bietet zusätzliche API-Endpunkte (z. B. für Checkout-Erweiterungen und B2B-Kataloge), ist aber für die meisten Automatisierungsszenarien keine Voraussetzung.

Wie lange dauert die Entwicklung einer Custom-Automatisierung?

Einfache Middleware (ein System angebunden, ein Workflow): 1–2 Wochen. Komplexe Multi-System-Integration mit Dashboard und Monitoring: 4–8 Wochen. Ich arbeite iterativ mit wöchentlichen Demos, sodass Sie früh Feedback geben können.

Weiterführende Artikel

  • Shopify Flow vs. Custom Automatisierung – Detaillierter Vergleich: Was Flow wirklich kann, wo seine harten Grenzen liegen und die 5-Fragen-Checkliste für die richtige Entscheidung.
  • Mechanic für Shopify: Der Praxis-Guide – Die Automatisierungsplattform, die die Lücke zwischen Flow und Custom App schließt — mit realem Multi-Store-Sync-Beispiel.
  • Shopify ERP-Integration – Wie SAP, Sage und andere ERP-Systeme sauber mit Shopify verbunden werden: Architekturen, Protokolle, typische Stolperfallen.
Teilen
Justin Kreutzmann

Geschrieben von

Justin Kreutzmann

Shopify-Entwickler für Custom Apps, ERP-Integrationen und Prozessautomatisierung. Ich helfe Marken, technische Grenzen zu überwinden — mit Lösungen, die im Alltag von Händlern wirklich funktionieren.

Projekt anfragen