“Custom Magento Development” steht auf der Startseite praktisch jeder Magento-Agentur – auch bei uns stand es dort einmal. Geben Sie den Begriff bei Google ein, und Sie bekommen eine Wand aus fast identischen Service-Seiten: ein Hero-Bild, drei Stichpunkte zu “maßgeschneiderten Lösungen” und ein Kontaktformular. Fast keine erklärt, was die Arbeit dahinter tatsächlich ist.
Das ist ein Problem, wenn Sie derjenige sind, der dafür bezahlt. “Custom” wird als Synonym für “teuer” oder “individuell” benutzt, ohne je das Engineering dahinter zu beschreiben. Hier also die unvermarktete Version: was Custom Magento Development als konkrete Arbeit tatsächlich bedeutet, wie es richtig gemacht aussieht im Vergleich zu schlecht gemacht – und warum der Preis eigentlich nichts mit dem Wort “Custom” zu tun hat.
Entfernt man die Marketing-Sprache, ist Custom Magento Development ein klar abgrenzbares Set an Engineering-Aufgaben:
Jeder dieser Punkte ist eine echte Engineering-Aufgabe mit einem Umfang, einer Reihe von Trade-offs und einer richtigen sowie einer falschen Art, sie umzusetzen. Keiner davon ist “wir machen Ihre Seite besonders.” Wenn eine Agentur Ihnen nicht sagen kann, in welche dieser sechs Kategorien Ihr Projekt fällt, hat sie es noch nicht abgegrenzt – sie hat nur einen Preis dafür genannt.
Das ist der Teil, der kompetentes Custom Magento Development tatsächlich von der Art unterscheidet, die achtzehn Monate später Probleme verursacht: wie sich der individuelle Code an den Magento-Core anbindet.
Die Architektur von Magento 2 bietet mehrere vorgesehene Wege, Verhalten zu ändern, ohne eine einzige Core-Datei anzufassen:
Jeder dieser Mechanismen lebt in seinem eigenen Modul, in `app/code` oder als sauberes Composer-Paket, vollständig vom Magento-Core trennbar. Das ist der Unterschied zwischen “Custom Development” und “Herumhacken.” Ein einzelnes Plugin lässt sich für sich allein mit `disabled=”true”` am zugehörigen `<plugin>`-Knoten in der di.xml deaktivieren – ohne den Rest des Moduls anzufassen. Eine direkte Bearbeitung einer Vendor-Datei hat kein Äquivalent dazu – sie wird beim nächsten `composer update` entweder stillschweigend überschrieben oder stillschweigend beibehalten (und weicht damit lautlos von dem ab, was `composer.lock` eigentlich behauptet).
Hier fließt bei einem gereiften Magento-Shop der Großteil des echten Custom-Development-Budgets hin – und es ist die Kategorie, über die generische Agentur-Texte am wenigsten sprechen, wahrscheinlich weil sie am wenigsten glamourös zu beschreiben ist.
Nichts davon ist optionaler Feinschliff. Bricht Ihre ERP-Integration lautlos, verkaufen Sie über oder unter Bestand, bis es jemand bemerkt – meist eine Kundenbeschwerde, kein Monitoring-Alert.
Jeder Magento-Shop erreicht irgendwann einen Punkt, an dem das Standardverhalten nicht mehr zu seiner spezifischen Form passt – nicht weil Magento generell langsam wäre, sondern weil Ihr Katalog, Ihr Traffic-Muster oder Ihre Kundendaten nicht das sind, worauf die Defaults des Frameworks getunt wurden. Custom Development sieht hier so aus:
Diese Kategorie taucht selten in einem Erstgespräch auf. Sie zeigt sich sechs Monate nach dem Launch, wenn der Katalog gewachsen ist und die Seite, die im Staging schnell wirkte, während eines Sales anfängt, Timeouts zu werfen.
Zwei Kategorien, die sich in der Praxis ständig überschneiden:
Hier wird auch häufig ein Großteil des “Custom Development”-Budgets falsch eingesetzt – man bezahlt für einen maßgeschneiderten Checkout-Flow, der etwas dupliziert, das Magento bereits gut kann, weil niemand vor der Abgrenzung neuen Codes geprüft hat, was schon vorhanden ist.
Daten zu migrieren – auf Magento, von Magento weg, oder zwischen Magento und einem angebundenen System – ist Custom Development, kein Skript, das man einmal laufen lässt. Produktattribute lassen sich nicht sauber zwischen Plattformen mappen. Bestellhistorien haben Randfälle (Teilrückerstattungen, Split-Lieferungen, Steuerneuberechnungen), die ein naiver Export/Import lautlos verstümmelt. Kundendaten müssen Kontoverknüpfung, Adressbücher und Bestellhistorie bewahren, ohne Datensätze zu duplizieren.
Richtig gemacht, umfasst eine Migration Validierung – Zählungen, Stichproben, Abgleichsberichte – nicht nur ein abgeschlossenes Import-Log. Schlecht gemacht, stellen Sie drei Monate später fest, dass 2 % der historischen Bestellungen ihre Steuerdaten auf Positionsebene verloren haben – genau dann, wenn das Finanzteam sie für einen Report braucht.
Hier liegt der Teil, der in zwei Jahren darüber entscheidet, ob Custom Magento Development ein Wert ist oder eine Last:
Im Vergleich dazu:
Die Kluft zwischen diesen beiden Ansätzen zeigt sich nicht am ersten Tag. Sie zeigt sich beim nächsten Magento-Upgrade, wenn “schlecht gemacht” zu einem Neubau wird, der als Upgrade getarnt ist, und “richtig gemacht” zu einer normalen Wartungsaufgabe.
Zwei Dinge lohnt es sich hier zu trennen. Erstens: echtes Custom Development – die Kategorien oben – kostet echte Engineering-Zeit, und diese Zeit kostet Geld, unabhängig davon, wer sie leistet oder wo diese Person sitzt. Wir haben an anderer Stelle schon geschrieben, warum unsere Kostenstruktur, aufgebaut um ein osteuropäisches Team, kein Race-to-the-bottom-Stundensatz ist – sondern eine andere Baseline als eine westeuropäische Agentur, die dieselben Stunden mit Aufschlag für dieselbe Adresse auf der Rechnung verkauft.
Zweitens, und für diesen Artikel relevanter: Ein großer Teil dessen, was Händler als “Custom Development” anfragen, ist eigentlich nur Konfiguration – Versandregeln, Kundengruppen und Katalogpreisregeln sind seit Magento 1 native, codefreie Admin-Panel-Einstellungen, nie etwas, das je einen Entwickler gebraucht hätte. Grundlegende B2B-Funktionen sind die echte Ausnahme: Das ist tatsächliche Funktionalität, die es in Magento 1 nie gab, hinzugekommen erst mit Magento 2 (genauer: dem B2B-Modul von Adobe Commerce). Ein Teil dessen, was als “Custom Development” verkauft wird, ist in Wahrheit reine Konfiguration, abgerechnet zum Entwicklungssatz – weil die Agentur die Plattform entweder nicht gut genug kennt, um den Unterschied zu erkennen, oder keinen Anreiz hat, darauf hinzuweisen.
Die ehrliche Version: Bezahlen Sie für Custom Development, wenn Sie Logik brauchen, die Magento wirklich nicht mitbringt. Bezahlen Sie keine Entwicklungssätze für Einstellungen, die Sie selbst ändern könnten, sobald Ihnen jemand zeigt, wo sie liegen.
Wir sind spezialisiert auf Magento 2 – Hyvä-Frontend-Entwicklung, Performance-Optimierung, die oben beschriebene Integrations- und Migrationsarbeit sowie B2B-Implementierungen. Zusätzlich warten wir Magento-1-Shops für Händler, die noch nicht bereit für den Wechsel sind. Wenn wir Custom Development abgrenzen, sagen wir Ihnen, welcher Teil davon wirklich individuell ist und welcher Teil Konfiguration, für die Sie nicht bezahlen müssen – denn genau das entscheidet, ob Ihr Magento-Shop in drei Jahren noch wartbar ist oder nicht.
Wenn Sie Custom-Magento-Development-Services evaluieren und einen Zuschnitt wollen, der echte Engineering-Arbeit von aufgeblähten Stunden trennt, nehmen Sie Kontakt auf.
