Was kostet ein individuelles JTL-Shop-Plugin?

Warum sich Pluginpreise nicht pauschal nennen lassen

Der Begriff JTL-Shop-Plugin beschreibt nur die technische Form der Erweiterung, nicht ihren Umfang.

Ein Plugin kann beispielsweise:

• einen festen Hinweis auf bestimmten Produktseiten ausgeben
• eigene Backend-Einstellungen bereitstellen
• Produktdaten nach mehreren Regeln auswerten
• Preise dynamisch berechnen
• Konfigurationen im Warenkorb speichern
• Bestelldaten an ein externes System übertragen
• umfangreiche Datenbestände verwalten
• mehrere JTL-Shops miteinander verbinden

Diese Funktionen unterscheiden sich erheblich bei Planung, Entwicklung, Prüfung und langfristiger Wartung.

Die wichtigsten Kostenfaktoren eines JTL-Shop-Plugins

Der Entwicklungsaufwand entsteht aus mehreren fachlichen und technischen Bereichen.

Die Anforderungsanalyse als eigener Projektteil

Je unklarer die Ausgangsidee, desto wichtiger wird eine vorgelagerte Analyse.

Zu klären sind unter anderem:

• Welches konkrete Problem soll gelöst werden?
• Wer verwendet die Funktion?
• Auf welchen Seiten wird sie benötigt?
• Welche Daten werden verwendet?
• Woher stammen diese Daten?
• Welche Regeln und Grenzwerte gelten?
• Welche Sonderfälle treten auf?
• Was muss nach erfolgreicher Verarbeitung geschehen?

Der Beitrag JTL-Shop-Plugin entwickeln lassen erläutert, wie Anforderungen vor dem Projektstart strukturiert werden.

Einfache Ausgabe oder vollständige Geschäftslogik?

Der Umfang hängt stark davon ab, ob vorhandene Daten nur angezeigt oder neue Regeln verarbeitet werden.

Je mehr dieser Schritte kombiniert werden, desto größer werden Entwicklung und Testumfang.

Wann eine Templateanpassung günstiger ist

Nicht jede gewünschte Änderung benötigt ein individuelles Plugin.

Eine Templateanpassung kann ausreichen, wenn:

• vorhandene Inhalte nur neu positioniert werden
• Farben, Abstände oder Schriftgrößen geändert werden
• ein bereits verfügbarer Artikelwert ausgegeben wird
• keine eigenen Einstellungen notwendig sind
• keine Daten gespeichert oder verarbeitet werden

Der Beitrag JTL-Shop-Plugin oder Templateanpassung zeigt die technischen Unterschiede ausführlich.

Eigene Backend-Einstellungen erhöhen den Umfang

Eine administrierbare Funktion ist langfristig komfortabler, benötigt aber zusätzliche Entwicklung.

Das Backend kann beispielsweise enthalten:

• Aktivierung einzelner Funktionen
• Texte und Übersetzungen
• Grenzwerte
• Kategorie- und Artikelzuordnungen
• Kundengruppen
• API-Zugangsdaten
• Protokolle
• Import- und Exportmöglichkeiten

Zusätzlich müssen Einstellungen validiert, gespeichert, migriert und nach Updates weiterverwendet werden können.

Frontend und mobile Darstellung

Eine sichtbare Shopfunktion muss auf verschiedenen Seiten und Geräten zuverlässig bedienbar sein.

Einfluss auf die Kosten haben:

• Anzahl betroffener Seitentypen
• Komplexität der Benutzerführung
• mobile Darstellung
• unterschiedliche Templates
• Mehrsprachigkeit
• Barrierefreiheit
• dynamische Eingaben und Rückmeldungen

Ein Formular auf einer einzelnen Inhaltsseite ist normalerweise einfacher als ein Produktkonfigurator mit abhängigen Auswahlmöglichkeiten und dynamischer Preisberechnung.

Warenkorb und Checkout als Kostentreiber

Erweiterungen im Kaufprozess benötigen besonders gründliche Prüfungen.

Zusätzlicher Aufwand entsteht, wenn das Plugin:

• Preise verändert
• individuelle Konfigurationen speichert
• Mindest- oder Höchstmengen prüft
• Versandarten beeinflusst
• Rabatte oder Zuschläge berechnet
• Bestellpositionen ergänzt
• Daten an JTL-Wawi übertragen muss

Produktseite, Warenkorb, Checkout, Bestellung und spätere Bearbeitung in JTL-Wawi müssen als zusammenhängender Prozess getestet werden.

Warum Preisberechnungen mehr Aufwand verursachen

Eine Preisberechnung muss nicht nur mathematisch korrekt sein.

Zu berücksichtigen können sein:

• Brutto- und Nettopreise
• Steuersätze
• Kundengruppen
• Staffelpreise
• Rabatte
• Währungen
• Mindestpreise
• Varianten
• Rundungsregeln

Zusätzlich muss verhindert werden, dass Werte ausschließlich im Browser manipuliert oder umgangen werden können.

Schnittstellen zu externen Systemen

Eine API-Anbindung erhöht den Aufwand durch technische und organisatorische Abhängigkeiten.

Entwickelt werden müssen häufig:

• Authentifizierung
• Zuordnung der Datenfelder
• Umwandlung von Formaten
• Zeitüberschreitungen
• Wiederholungsversuche
• Schutz vor doppelten Übertragungen
• Protokollierung
• Benachrichtigung bei Fehlern

Eine vollständig dokumentierte und stabile API reduziert den Analyseaufwand. Unvollständige Dokumentation oder wechselnde Testdaten erhöhen ihn.

API-Zugang allein reicht nicht für eine Aufwandsschätzung

Vor einem belastbaren Angebot muss geprüft werden, welche Funktionen die Schnittstelle tatsächlich bereitstellt.

Relevant sind:

• verfügbare Endpunkte
• Beispieldaten
• Übertragungslimits
• Testzugang
• Fehlerantworten
• Aktualität der Dokumentation
• zuständiger technischer Ansprechpartner

Eigene Datenbanktabellen und Migrationen

Sobald ein Plugin eigene Daten dauerhaft speichert, muss ihr vollständiger Lebenszyklus geplant werden.

Dazu gehören:

• Anlegen der Tabellen
• Validierung der Daten
• Indizes und Performance
• Änderungen bei neuen Versionen
• Migration vorhandener Datensätze
• Export und Löschung
• Verhalten bei Deaktivierung
• Verhalten bei Deinstallation

Ein Plugin, das nur vorhandene Shopdaten liest, ist normalerweise einfacher als eine Erweiterung mit eigener umfangreicher Datenhaltung.

Mehrsprachigkeit als zusätzlicher Aufwand

Mehrsprachige Plugins benötigen mehr als eine einmalige Übersetzung.

Sprachabhängig können sein:

• Beschriftungen
• Hilfetexte
• Fehlermeldungen
• Bestätigungen
• E-Mails
• Backendinhalte
• gespeicherte redaktionelle Texte

Zusätzlich müssen fehlende Übersetzungen und unterschiedliche Textlängen in der Darstellung berücksichtigt werden.

Kundengruppen und unterschiedliche Berechtigungen

Eine Funktion kann abhängig von Kundenstatus oder Benutzerrolle unterschiedlich arbeiten.

Zu prüfen sind:

• Gast oder angemeldeter Kunde
• Privat- oder Geschäftskunde
• unterschiedliche Kundengruppen
• Netto- und Bruttopreise
• individuelle Freigaben
• Backendrechte

Jede zusätzliche Regelkombination vergrößert die Anzahl notwendiger Testfälle.

Unterstützte JTL-Shop-Versionen

Die Zahl unterstützter Umgebungen beeinflusst Entwicklung und Qualitätssicherung.

Relevant sind:

• aktuelle produktive JTL-Shop-Version
• weitere zu unterstützende Versionen
• PHP-Versionen
• eingesetzte Templates
• weitere aktive Plugins

Eine Erweiterung für einen einzelnen bekannten Shop ist leichter zu testen als ein allgemein vertriebenes Plugin für zahlreiche Versionen und Templates.

Individuelles Kundenplugin oder öffentliches Standardplugin?

Ein öffentlich vertriebenes Plugin benötigt zusätzliche Funktionen und organisatorische Prozesse.

Dazu können gehören:

• Unterstützung verschiedener Shopumgebungen
• Lizenzverwaltung
• allgemeine Installationsroutinen
• umfangreichere Dokumentation
• Support für unterschiedliche Konfigurationen
• Veröffentlichungs- und Updateprozess

Ein individuell für eine bekannte Umgebung entwickeltes Plugin kann enger auf den tatsächlichen Einsatz abgestimmt werden.

Design und individuelle Darstellung

Der visuelle Umfang eines Plugins kann von einer einfachen Standardausgabe bis zu einer vollständigen eigenen Benutzeroberfläche reichen.

Den Aufwand beeinflussen:

• Anzahl der Ansichten
• individuelle Gestaltung
• responsive Verhalten
• Animationen
• Schritt-für-Schritt-Prozesse
• Livevorschauen
• Interaktion mit Produktbildern

Ein funktionaler Prototyp kann bei komplexen Oberflächen helfen, die Bedienung frühzeitig abzustimmen.

Warum Tests ein relevanter Kostenbestandteil sind

Entwicklung ohne ausreichende Prüfung verlagert Kosten und Risiken in den produktiven Betrieb.

Abhängig von der Funktion müssen geprüft werden:

• Installation
• Backend-Einstellungen
• unterschiedliche Produktarten
• Varianten
• Kundengruppen
• mehrere Sprachen
• mobile Darstellung
• Warenkorb und Checkout
• Bestellübernahme
• Schnittstellenfehler
• Pluginupdates

Je stärker eine Erweiterung Preise, Bestellungen oder externe Daten beeinflusst, desto umfangreicher muss der Testplan ausfallen.

Dokumentation und Schulung

Eine Erweiterung muss auch nach Monaten noch verständlich bedient und gewartet werden können.

Benötigt werden können:

• Installationsanleitung
• Erklärung der Einstellungen
• Beschreibung der Geschäftsregeln
• Fehlerbehandlung
• Updatehinweise
• Schulung der Administratoren
• technische Entwicklerdokumentation

Der Umfang hängt davon ab, ob nur ein technischer Administrator oder ein größeres Team mit der Funktion arbeitet.

Updatefähigkeit verursacht zunächst Aufwand und spart später Kosten

Eine sauber strukturierte Erweiterung ist häufig nicht die schnellste erste Umsetzung, reduziert aber spätere Risiken.

Dazu gehören:

• Trennung vom Shopkern
• versionierte Datenbankmigrationen
• klare Abhängigkeiten
• Versionsverwaltung
• wiederholbare Testfälle
• Dokumentation

Der Beitrag Updatefähige JTL-Shop-Plugins zeigt, wie Erweiterungen langfristig wartbar aufgebaut werden.

Einmalige Entwicklung und laufende Kosten trennen

Für eine realistische Budgetplanung sollten Investition und späterer Betrieb getrennt betrachtet werden.

Festpreis oder Abrechnung nach Aufwand?

Die geeignete Abrechnungsform hängt vom Reifegrad der Anforderungen ab.

Ein Festpreis ist eher möglich, wenn:

• der Funktionsumfang eindeutig beschrieben ist
• Datenquellen und Schnittstellen bekannt sind
• Sonderfälle feststehen
• unterstützte Versionen definiert sind
• Abnahmekriterien vereinbart wurden

Eine Abrechnung nach Aufwand oder in Projektphasen ist sinnvoller, wenn zunächst technische Machbarkeit, Datenqualität oder das Verhalten einer externen API untersucht werden müssen.

Warum eine Konzeptphase separat sinnvoll sein kann

Bei größeren Pluginideen kann zunächst nur Analyse und technisches Konzept beauftragt werden.

Das Ergebnis kann enthalten:

• fachliche Prozessbeschreibung
• Datenquellen
• Datenmodell
• Backend- und Frontendbereiche
• Schnittstellen
• Risiken
• Testumfang
• Umsetzungsphasen
• belastbarere Kosteneinschätzung

Das Unternehmen kann anschließend auf einer besseren Entscheidungsgrundlage über die vollständige Entwicklung entscheiden.

Machbarkeitsanalyse bei technischen Unsicherheiten

Manche Fragen können erst durch einen begrenzten technischen Test zuverlässig beantwortet werden.

Das betrifft beispielsweise:

• Verfügbarkeit bestimmter JTL-Shop-Daten
• geeignete Hooks
• Übernahme individueller Angaben in JTL-Wawi
• Verhalten einer externen API
• Performance großer Datenmengen
• Kompatibilität mit einem vorhandenen Plugin

Eine begrenzte Machbarkeitsanalyse kann eine teure Fehlplanung vermeiden.

Die erste Pluginversion wirtschaftlich begrenzen

Nicht jede gewünschte Komfortfunktion muss bereits in Version 1.0 enthalten sein.

Die erste Version sollte:

• den zentralen Prozess vollständig abbilden
• kritische Fehlerfälle behandeln
• sicher installierbar sein
• messbaren Nutzen erzeugen
• spätere Erweiterungen ermöglichen

Zusätzliche Auswertungen, weitere Darstellungsoptionen und selten benötigte Sonderfälle können nach der ersten realen Nutzung priorisiert werden.

Beispiel für eine sinnvolle Aufteilung

Ein Produktkonfigurator muss nicht sofort jede denkbare Produktgruppe unterstützen.

1. Version 1 verarbeitet eine wichtige Produktgruppe mit klaren Regeln.
2. Nach dem Go-live werden Nutzung und Fehler ausgewertet.
3. Version 2 ergänzt weitere Produkte und Komfortfunktionen.
4. Zusätzliche Auswertungen folgen nur bei tatsächlichem Bedarf.

Dadurch wird der wirtschaftliche Nutzen früher erreicht und das Projektrisiko reduziert.

Änderungswünsche während der Entwicklung

Neue Erkenntnisse sind in Softwareprojekten normal, verändern aber gegebenenfalls Aufwand und Zeitplan.

Bei jeder Erweiterung sollte geprüft werden:

• Ändert sich das Datenmodell?
• Werden neue Benutzerrollen benötigt?
• Sind zusätzliche Ansichten erforderlich?
• Verändert sich die Schnittstelle?
• Welche neuen Testfälle entstehen?
• Kann die Funktion in eine spätere Version verschoben werden?

Eine saubere Änderungsbewertung verhindert, dass der Projektumfang unkontrolliert wächst.

Welche Angaben für eine erste Kosteneinschätzung benötigt werden

Je genauer die Ausgangsinformationen sind, desto belastbarer kann der Aufwand eingeordnet werden.

Hilfreich sind:

• Beschreibung des aktuellen Problems
• gewünschter Zielablauf
• betroffene Seiten und Benutzer
• verwendete Daten
• Regeln und Berechnungen
• bekannte Sonderfälle
• JTL-Shop-Version
• eingesetztes Template
• relevante vorhandene Plugins
• API-Dokumentation
• Beispieldaten und Screenshots

Warum kleine Plugins trotzdem professionell geplant werden müssen

Ein begrenzter Funktionsumfang bedeutet nicht, dass Sicherheit und Updatefähigkeit unwichtig werden.

Auch ein kleines Plugin kann:

• Produktpreise beeinflussen
• personenbezogene Daten verarbeiten
• den Warenkorb verändern
• mit anderen Erweiterungen kollidieren
• nach einem Shopupdate ausfallen

Planung und Tests können kompakter ausfallen, sollten aber weiterhin zur möglichen Auswirkung der Funktion passen.

Wie sich die Kosten wirtschaftlich bewerten lassen

Der Projektpreis sollte dem erwarteten Nutzen gegenübergestellt werden.

Berücksichtigt werden können:

• eingesparte Arbeitsstunden
• vermiedene Fehlerkosten
• zusätzlicher Deckungsbeitrag
• schnellere Bearbeitung
• geringere Personalabhängigkeit
• laufende Wartungskosten
• geplanter Nutzungszeitraum

Der Beitrag Wann lohnt sich ein individuelles JTL-Plugin wirtschaftlich? zeigt eine ausführliche Wirtschaftlichkeitsbewertung.

Günstige Standardlösung oder individuelle Entwicklung?

Vor jeder Neuentwicklung sollten vorhandene Alternativen geprüft werden.

Dazu gehören:

• JTL-Shop-Standardfunktionen
• Templateeinstellungen
• bestehende kostenlose Plugins
• kostenpflichtige Standardplugins
• externe Skripte oder Tools
• Prozessanpassungen

Einen Überblick bietet die Seite Plugins und Erweiterungen. Kostenlose Lösungen finden Sie unter Kostenlose JTL-Shop-Plugins.

Wann eine Standardlösung trotz Einschränkungen sinnvoll ist

Nicht jede Abweichung rechtfertigt ein eigenes Entwicklungsprojekt.

Eine vorhandene Lösung kann wirtschaftlicher bleiben, wenn:

• sie den Kernprozess zuverlässig abbildet
• nur seltene Sonderfälle manuell bearbeitet werden
• der eigene Prozess leicht angepasst werden kann
• regelmäßige Herstellerupdates verfügbar sind
• Lizenzkosten deutlich unter einer Neuentwicklung liegen

Typische Fehler bei der Einschätzung von Plugin-Kosten

Viele falsche Erwartungen entstehen durch eine unvollständige Betrachtung des Projekts.

Wie ein belastbares Pluginangebot aufgebaut sein sollte

Das Angebot sollte erkennen lassen, welche Leistungen und Annahmen enthalten sind.

Sinnvolle Bestandteile sind:

• Beschreibung des Funktionsumfangs
• betroffene Shopbereiche
• unterstützte Versionen
• Datenquellen und Schnittstellen
• Backend- und Frontendfunktionen
• Testumfang
• Dokumentation
• Mitwirkungspflichten des Auftraggebers
• nicht enthaltene Leistungen
• Regelung für spätere Änderungswünsche

Ein sinnvoller Projektablauf

Die Kosten werden schrittweise präziser, sobald fachliche und technische Unsicherheiten reduziert werden.

Wie Faymax Consulting Plugin-Kosten ermittelt

Faymax Consulting bewertet zunächst, welche technische Lösung für die Anforderung wirklich notwendig ist.

Geprüft werden:

• vorhandene JTL-Shop-Funktionen
• mögliche Templateanpassungen
• bestehende Plugins
• fachlicher Prozess
• Datenquellen und Geschäftsregeln
• Backend und Frontend
• Schnittstellen
• Test- und Wartungsbedarf

Erst danach wird entschieden, ob ein individuelles Plugin notwendig ist und wie der Funktionsumfang wirtschaftlich begrenzt werden kann.

Dabei wird nicht nur die erste Entwicklung betrachtet. Updatefähigkeit, Dokumentation und spätere Betreuung werden bereits während der Planung berücksichtigt.

Häufige Fragen zu den Kosten eines JTL-Shop-Plugins