Ein Kunde legte uns seine Überlegung ausführlich dar: Sein bisheriges Shopsystem läuft aus, der Nachfolger überzeugt ihn nicht – zu teuer im Verhältnis zu seinen Umsätzen, umständlich in der Bedienung, wichtige Funktionen fehlen weiterhin. Gehostete Lösungen scheiden aus, weil er direkten Zugriff auf die Datenbank für seine eigenen Werkzeuge braucht. Und jede Alternative bedeutet aus seiner Sicht wieder eine neue Abhängigkeit von der Existenz und Preispolitik eines fremden Unternehmens.
Also: selbst entwickeln?
Die beiden Antworten aus der Runde waren ungewöhnlich eindeutig – und sie sind zusammengenommen die beste Entscheidungshilfe zu dieser Frage, die ich kenne.
Die kurze Antwort
Die erste Einschätzung: Mit einem Team von zehn bis zwanzig Entwicklern kann man das angehen – und selbst dann dauert es mindestens ein Jahr bis zu einem ersten lauffähigen Stand. Ohne ein solches Team: lassen. Shop und Warenwirtschaft technisch sauber aufzusetzen sei ziemlich genau die Königsdisziplin, an der sich auch Profis die Zähne ausbeißen.
Die zweite kam von jemandem mit zwanzig Jahren Erfahrung und mehreren Systemwechseln hinter sich. Sein Punkt: Der Umfang wächst permanent. Schnittstellen zu Warenwirtschaft, Buchhaltung, Versanddienstleistern, Marktplätzen, Zahlungsanbietern und Onlinebanking, dazu Rechtsthemen, Suchmaschinenoptimierung, Einwilligungsverwaltung, Newsletter, mobile Darstellung, Gestaltung, Bilder, Texte. Früher habe er das allein gemacht – heute gehe es ohne Team und Agenturunterstützung nicht mehr. Und allein die rechtlichen Grundlagen einzuhalten sei für eine Person schlicht unmöglich.
Zusammengefasst: Die Frage ist nicht, ob man einen Shop programmieren kann. Die Frage ist, ob man ihn zehn Jahre lang aktuell halten kann.
Die eigentliche Frage hinter der Frage
Der Wunsch nach Eigenentwicklung entsteht selten aus Begeisterung für Softwareprojekte. Er entsteht aus drei konkreten Ärgernissen – und für jedes davon gibt es günstigere Antworten:
„Ich will nicht von der Preispolitik eines Anbieters abhängen.“
Verständlich. Aber die Alternative ist keine Unabhängigkeit, sondern eine andere Abhängigkeit: von deinem Entwickler, von einem Framework, von Bibliotheken, die gepflegt werden müssen. Was du realistisch erreichen kannst, ist nicht Unabhängigkeit, sondern Wechselfähigkeit.
„Ich brauche direkten Zugriff auf die Daten.“
Das ist ein legitimes und lösbares Kriterium. Es spricht gegen geschlossene gehostete Lösungen, aber nicht für Eigenentwicklung – selbst gehostete offene Systeme erfüllen es ebenfalls.
„Funktionen, die ich brauche, fehlen.“
Hier lohnt die genaue Prüfung: Wie viele sind es, wie groß ist der Aufwand für Erweiterungen, und ließe sich das über eigene Werkzeuge an der Schnittstelle lösen, statt das Kernsystem zu ersetzen?
Wenn du diese drei Punkte für dich getrennt beantwortest, schrumpft das Projekt in den allermeisten Fällen von „eigener Shop“ auf „drei Erweiterungen und ein Datenexport“.
Was Eigenentwicklung wirklich kostet
Die Erstentwicklung ist der kleinere Teil. Teuer wird der Betrieb:
Rechtsänderungen. Pflichtangaben, Widerrufsrecht, Preisangaben, Produktsicherheit, Einwilligungen. Bei einem Standardsystem kommt das als Update, bei einer Eigenentwicklung als Auftrag.
Fremdsysteme, die sich ändern. Zahlungsanbieter ändern Schnittstellen, Marktplätze führen Pflichtfelder ein, Versanddienstleister stellen Formate um. Jede dieser Änderungen ist bei dir ein kleines Projekt.
Sicherheit. Ein Shop verarbeitet Zahlungs- und Personendaten. Aktualisierungen, Prüfungen und Absicherung sind kein Projektposten, sondern eine Daueraufgabe.
Und der Punkt, der am häufigsten unterschätzt wird: die Abhängigkeit von einer Person. Im Ausgangsfall stand bereits im Text, dass der eigene Programmierer das nicht nebenher leisten kann. Selbst wenn er es könnte – dann hinge das gesamte Unternehmen an einem einzigen Menschen mit Urlaub, Krankheit und der Möglichkeit, zu kündigen.
Die Zwischenwege
Zwischen „Standardsystem hinnehmen“ und „alles selbst bauen“ liegen mehrere Optionen, die im Ausgangsfall nicht erwähnt wurden:
Selbst gehostetes offenes System. Erfüllt den Wunsch nach Datenzugriff und eigener Infrastruktur, ohne dass du den Kern selbst wartest.
Standard-Backend mit eigenem Frontend. Die Verkaufsoberfläche selbst gestalten und dabei die gesamte Kaufabwicklung, Rechtstexte und Zahlungsanbindung im Standard belassen. Damit bekommst du Gestaltungsfreiheit ohne die Wartungslast am kritischen Teil.
Eigene Werkzeuge an der Schnittstelle. Genau das, was der Fragesteller ohnehin macht: Die Sonderlogik läuft in eigenen Programmen, die auf die Daten des Standardsystems zugreifen. Das ist der pragmatischste Weg – Standard für alles, was jeder braucht, Eigenbau für das, was dich unterscheidet.
Wechselfähigkeit statt Unabhängigkeit. Vollständiger Datenexport, dokumentiertes Datenmodell, keine Sonderentwicklungen im Kern. Damit bist du nicht unabhängig, aber du kannst gehen – und das ist in Verhandlungen mehr wert als jede Eigenentwicklung.
Schritt für Schritt: Die Entscheidung
Schritt 1 – Die Ziele einzeln aufschreiben
Nicht „eigener Shop“, sondern: Datenzugriff, drei fehlende Funktionen, planbare Kosten, unabhängige Weiterentwicklung. Je konkreter, desto eher findest du eine günstigere Lösung.
Schritt 2 – Jedes Ziel gegen Standardsysteme prüfen
Mit Testfällen statt Funktionslisten – und mit Anbietern, die dein Volumen und deine Kanäle kennen.
Schritt 3 – Den Datenzugriff klären
Datenbankzugriff, dokumentierte Schnittstelle oder vollständiger Export? Eines davon reicht meist aus, um eigene Werkzeuge zu betreiben.
Schritt 4 – Die Gesamtkosten über fünf Jahre rechnen
Beide Varianten: Lizenz, Hosting, Erweiterungen, Betreuung – gegen Entwicklung, Wartung, Rechtsanpassungen, Sicherheitsaufwand, Ausfallrisiko und den Zeitverlust bis zur Betriebsbereitschaft.
Setz für die Eigenentwicklung mindestens ein Jahr bis zum ersten produktiven Stand an, so wie in der Diskussion genannt – und in dieser Zeit läuft dein Geschäft auf dem alten System weiter.
Schritt 5 – Den Bus-Faktor prüfen
Wie viele Menschen könnten dein System betreiben, wenn eine Person morgen ausfällt? Bei der Antwort „eine“ ist die Entscheidung getroffen.
Schritt 6 – Die Zwischenwege durchspielen
Bevor du das Kernsystem ersetzt: Lässt sich dasselbe Ziel mit eigenen Werkzeugen an der Schnittstelle erreichen?
Schritt 7 – Wechselfähigkeit absichern
Export, Datenmodell, Vertragslaufzeiten, Preisanpassungsklauseln. Das ist die realistische Version dessen, was du eigentlich willst.
Schritt 8 – Wenn doch Eigenentwicklung: mit Plan
Team statt Einzelperson, klar abgegrenzter erster Funktionsumfang, Parallelbetrieb, dokumentierter Code, und eine ehrliche Antwort darauf, wer das in fünf Jahren pflegt.
Wann Eigenentwicklung wirklich sinnvoll ist
Es gibt diese Fälle. Sie haben eines gemeinsam: Die Software ist Teil des Produkts, nicht nur Werkzeug.
Wenn dein Geschäftsmodell auf einer Funktion beruht, die kein Standardsystem abbildet – Konfiguratoren für komplexe Produkte, besondere Preislogiken, ungewöhnliche Vertriebsmodelle –, dann ist Eigenbau nicht Selbstzweck, sondern Wettbewerbsvorteil.
Und selbst dann gilt der Rat aus der Runde: nur mit einem Team, und mit einem realistischen Zeitplan.
FAQ
Kann ich meinen Shop selbst entwickeln lassen?
Technisch ja. Realistisch braucht es dafür ein Team, mindestens ein Jahr bis zum ersten produktiven Stand und eine dauerhafte Wartungskapazität.
Was ist der teuerste Teil?
Nicht die Entwicklung, sondern der Betrieb: Rechtsänderungen, sich ändernde Schnittstellen von Zahlungsanbietern und Marktplätzen, Sicherheit.
Werde ich damit unabhängig?
Nein. Du tauschst die Abhängigkeit vom Anbieter gegen die von deinem Entwicklerteam. Erreichbar ist Wechselfähigkeit, nicht Unabhängigkeit.
Was ist der beste Kompromiss?
Standardsystem für alles, was jeder braucht – eigene Werkzeuge an der Schnittstelle für das, was dich unterscheidet.
Wann lohnt sich Eigenentwicklung wirklich?
Wenn die Software selbst Teil deines Wettbewerbsvorteils ist und du ein Team hast, das sie dauerhaft pflegen kann.
Fazit
Der Wunsch nach einem eigenen Shop ist fast immer der Wunsch nach Kontrolle. Der Weg dorthin führt aber selten über die Eigenentwicklung – sondern über konkrete Antworten auf konkrete Ärgernisse.
Schreib auf, was dich stört. In den meisten Fällen stellt sich heraus, dass drei Erweiterungen, ein Datenexport und ein Vertrag mit vernünftigen Kündigungsfristen dasselbe leisten wie ein Projekt, das ein Jahr dauert und danach nie fertig ist.