Magento Entwickler beauftragen: Backend, Hyvä und Schnittstellen
MAGENTO ENTWICKLERBackend, Hyvä-Frontend und Schnittstellen
Magento Entwickler beauftragen: sauberer Code, faire Stunden
Du brauchst einen Magento Entwickler für ein Modul, einen Umbau oder die laufende Weiterentwicklung Deines Shops? Wir setzen Magento nach den Regeln der Plattform um, dokumentieren, was wir ändern, und rechnen transparent zu 30 Euro pro Stunde ab.
Für viele Shop-Betreiber ist die Suche nach einem Magento Entwickler ein Dauerthema. Gute Leute sind selten, Stellenanzeigen laufen Monate, und wenn jemand gefunden ist, fehlt oft die Erfahrung mit Hyvä oder mit der Anbindung an Warenwirtschaft und PIM. Eine Beauftragung auf Stundenbasis umgeht dieses Nadelöhr.
Wir sind eine Webagentur aus festen Freelancern, die alle remote arbeiten, und entwickeln seit 2012 für Magento. Auf dieser Seite steht, was einen guten Magento Entwickler ausmacht, nach welchen Standards wir arbeiten und wie ein Einstieg in Deinen bestehenden Shop abläuft. Wenn Du eher eine einzelne Person für ein klar umrissenes Projekt suchst, passt auch die Seite Magento Freelancer.
01
Magento Entwickler beauftragen oder einstellen?
Beides kann richtig sein. Die Entscheidung hängt vom Arbeitsvolumen ab, nicht vom Bauchgefühl:
Kriterium
Eigene Stelle
Beauftragung
Zeit bis zum Start
Ausschreibung, Auswahl und Kündigungsfristen: oft mehrere Monate
Nach Erstgespräch und Absprache, meist deutlich kürzer
Kosten
Gehalt, Nebenkosten, Arbeitsplatz und Weiterbildung, auch in ruhigen Wochen
Nur die geleisteten Stunden
Spezialwissen
Ein Profil muss alles abdecken
Gezielter Zugriff auf Backend, Hyvä und Integrationen
Auslastung
Lohnt sich bei dauerhaft vollem Backlog
Lohnt sich bei schwankendem oder punktuellem Bedarf
Wissen im Haus
Bleibt im Unternehmen
Wird durch Dokumentation und Git übergeben
Faustregel: Wer dauerhaft eine volle Stelle mit Magento-Arbeit füllt, sollte einstellen. Wer Spitzen abdecken, einmalige Projekte umsetzen oder eine bestimmte Fachrichtung dazuholen will, fährt mit einer Beauftragung günstiger.
02
Was einen guten Magento Entwickler ausmacht
Magento ist ein umfangreiches Framework. Diese Fähigkeiten trennen Routine von Erfahrung:
Architekturverständnis
Dependency Injection, Plugins, Observer, Service Contracts und die Frage, wann welches Mittel sauber ist.
Datenhaltung
EAV, Indexer, Caches und deklaratives Schema. Wer das nicht kennt, baut langsame Shops.
Modernes Frontend
Hyvä mit Tailwind CSS und Alpine.js, dazu Verständnis für Core Web Vitals.
Werkzeuge
Composer, Git, Docker, CLI und Xdebug gehören zum Alltag, nicht zum Sonderfall.
Sicherheitsbewusstsein
Eingaben validieren, Rechte über ACL steuern, Security-Patches zeitnah einspielen.
Kommunikation
Aufwand ehrlich schätzen, Risiken früh nennen und verständlich erklären, was geändert wurde.
03
Nach diesen Standards entwickeln wir als Magento Entwickler
Wir schreiben PHP mit strikten Typen und nutzen Constructor Property Promotion für Dependency Injection. Geschäftslogik steckt in Services und Repositories, nicht in Controllern. Datenbankänderungen laufen über das deklarative Schema, nicht über Install-Skripte.
Wo Magento ein Verhalten ändern lässt, bevorzugen wir Plugins statt Preferences und niemals Eingriffe in den Core. Das hält Updates beherrschbar. Jedes neue Modul bekommt eigene Einstellungen im Admin mit Konfigurationsbereich und Berechtigungen, damit Du Funktionen ohne Entwickler steuern kannst.
Vor der Übergabe prüfen wir den Code mit PHPStan auf Level 5 und mit PHPCS. Das fängt Typfehler und Stilbrüche ab, bevor sie im Shop auffallen. Bei Frontend-Arbeit gilt dasselbe Prinzip: keine Fremdbibliotheken ohne Grund, kein zusätzliches JavaScript, wo Alpine.js reicht.
Warum das für Dich zählt
Code, der sich an die Regeln der Plattform hält, übersteht Updates, lässt sich von anderen Entwicklern übernehmen und verursacht weniger Folgekosten.
04
Welche Magento Entwickler-Leistungen Du bei uns bekommst
Je nach Aufgabe arbeiten wir als Backend-, Frontend- oder Integrationsentwickler:
So steigt ein Magento Entwickler in Deinen Shop ein
Bei einem bestehenden Shop beginnt jede Zusammenarbeit mit Orientierung. Das spart später Zeit.
01
Zugang
Zugriff auf Repository, Staging und Admin mit eigenem Benutzer, nicht mit geteilten Zugangsdaten.
02
Bestandsaufnahme
Wir lesen den Code, prüfen Module und Patches und halten Auffälligkeiten schriftlich fest.
03
Priorisierung
Gemeinsam sortieren wir Aufgaben nach Nutzen und Risiko, einfache Gewinne zuerst.
04
Umsetzung
Arbeit in kleinen Schritten mit Abnahme auf dem Testsystem, bevor etwas live geht.
Wenn Du nicht weißt, in welchem Zustand Dein Shop ist, beginnen wir mit einem Code-Audit. Das Ergebnis ist eine priorisierte Liste, mit der Du auch einen anderen Anbieter beauftragen könntest.
06
Was ein Magento Entwickler in der Praxis löst
Hinter den Leistungsbereichen stehen konkrete Probleme. Vier Beispiele aus der Praxis:
Kundenspezifische Preise und Konditionen
Preislisten pro Kundengruppe, Staffelpreise und Rabatte, die aus dem ERP kommen und im Shop ohne Handarbeit ankommen. Die Herausforderung ist die Reihenfolge: Welche Regel gewinnt, wenn mehrere gelten?
Große Katalog-Importe
Zehntausende Artikel aktualisieren, ohne den Shop zu blockieren. Wir arbeiten mit Batches und Warteschlangen, schreiben ein Protokoll und sorgen dafür, dass ein Fehler nicht den ganzen Lauf abbricht.
Erweiterungen im Admin
Eigene Grids, Formulare und Konfigurationsbereiche, die Dein Team nutzen kann, ohne einen Entwickler zu fragen. Berechtigungen steuern, wer was sieht.
APIs für App und Headless
Erweiterte REST- und GraphQL-Schnittstellen, damit eine mobile App oder ein entkoppeltes Frontend genau die Daten bekommt, die es braucht, und nicht mehr.
Wer einen Teil davon als fertiges Produkt braucht, findet im Modulkatalog erprobte Erweiterungen. Für alles andere entwickeln wir individuell.
07
Abrechnung: So bezahlst Du einen Magento Entwickler
Unser Stundensatz liegt bei 30 Euro. Er gilt für alle Entwicklerrollen. Zusätzlich gibt es feste Modelle für wiederkehrenden Bedarf:
Modell
Leistung
Preis
Einzelauftrag
Entwicklung nach Aufwand oder als Festpreis nach Erstgespräch
Eine Schätzung enthält immer, was wir einbeziehen, was nicht und welche Annahmen dahinterstehen. Wird ein Aufwand absehbar größer, melden wir uns, bevor das Budget aufgebraucht ist.
08
Fünf Fehler, wenn Du einen Magento Entwickler beauftragst
Diese Muster sehen wir in übernommenen Shops immer wieder:
Änderungen im Core
Wer Magento-Dateien direkt ändert, verliert beim nächsten Update die Änderung oder den Shop.
Kein Testsystem
Neue Funktionen direkt im Live-Shop zu probieren kostet im Zweifel Umsatz.
Geteilte Zugangsdaten
Ohne eigenen Benutzer lässt sich nicht nachvollziehen, wer was geändert hat.
Auftrag ohne Abnahmekriterium
Ohne klare Definition von "fertig" wird jede Abrechnung zur Diskussion.
Drittmodule ohne Pflege
Module ohne Updates sind eine der häufigsten Ursachen für Sicherheitslücken und gescheiterte Magento-Updates.
09
Hyvä oder Luma: Welchen Entwickler brauchst Du?
Das klassische Luma-Theme baut auf Knockout, jQuery und RequireJS auf. Ein Magento Entwickler, der nur dieses Wissen mitbringt, kann einen Hyvä-Shop nur eingeschränkt pflegen. Bei Hyvä kommen Tailwind CSS und Alpine.js zum Einsatz, die Seiten laden mit sehr viel weniger JavaScript. Eine Übersicht dazu findest Du auf der Seite Magento Hyvä.
Wenn Dein Shop noch auf Luma läuft und Du über einen Wechsel nachdenkst, ist der Zeitpunkt günstig, die Entwicklerfrage gleich mitzuklären. Wer heute ein Hyvä-Theme baut, braucht später auch jemanden, der es versteht. Das gilt unabhängig davon, ob Du uns beauftragst oder nicht.
10
Was macht ein Magento Entwickler bei der Moduleentwicklung?
Ein eigenes Modul beginnt nicht mit Code, sondern mit der Frage, an welcher Stelle Magento die gewünschte Änderung vorsieht. Ein erfahrener Magento Entwickler schaut zuerst, ob ein Konfigurationswert, ein Event oder ein Plugin genügt, bevor er Klassen ersetzt. Je kleiner der Eingriff, desto geringer das Risiko beim nächsten Update.
Die öffentliche Schnittstelle eines Moduls legen wir über Service Contracts fest: Interfaces für Daten und Repositories für den Zugriff. Andere Module und die API sprechen mit diesen Interfaces, nicht mit der konkreten Klasse dahinter. So lässt sich die Implementierung später ändern, ohne dass abhängiger Code bricht.
Neue Tabellen und Spalten beschreiben wir im deklarativen Schema. Magento vergleicht den gewünschten Zustand mit der Datenbank und leitet die nötigen Änderungen selbst ab. Für Inhalte und Einstellungen, die einmalig angelegt werden müssen, nutzen wir Data Patches. Sie laufen genau einmal und sind im Repository nachvollziehbar versioniert.
Plugins setzen wir dort ein, wo Verhalten vor, nach oder um eine öffentliche Methode herum ergänzt werden soll. Ein Beispiel: Soll der Versandpreis ab einem bestimmten Warenwert entfallen, genügt meist ein Plugin auf die Berechnung. Eine Preference ersetzt dagegen eine ganze Klasse und kollidiert schnell mit anderen Modulen, die dieselbe Klasse anfassen. Deshalb ist sie für uns die Ausnahme und muss begründet sein.
11
Hyvä-Frontend aus Sicht des Magento Entwicklers
Im Frontend entscheidet sich, ob ein Shop schnell wirkt und sich später pflegen lässt. Bei Hyvä achten wir auf diese Punkte:
Child-Theme statt Eingriff ins Parent-Theme
Anpassungen liegen in einem eigenen Theme, das vom Hyvä-Theme erbt. Updates des Parent-Themes lassen sich dann einspielen, ohne dass eigene Änderungen überschrieben werden.
Tailwind mit Maß
Klassen kommen direkt ins Template. Wiederkehrende Muster wandern in Komponenten, damit nicht dieselbe Klassenkette an zehn Stellen steht. Wichtig ist, dass der Build neue Klassen auch tatsächlich kennt.
Alpine.js für Interaktion
Menüs, Tabs, Mengenwähler und ähnliche Elemente brauchen kleine Alpine-Komponenten, keine Bibliothek. Das hält die Seite leicht und den Code lesbar.
Inline-Skripte mit Content Security Policy
Wo das Hyvä-CSP-Theme zum Einsatz kommt, müssen Inline-Skripte sauber registriert werden. Sonst blockiert der Browser sie, und die Funktion fällt still aus.
Layout über XML
Änderungen an der Seitenstruktur steuern wir über Layout-XML und Handles, nicht über Sonderfälle im Template. So bleibt nachvollziehbar, wo ein Block herkommt.
Kompatibilität von Modulen
Drittmodule mit Luma-Frontend brauchen für Hyvä oft eine Kompatibilitätsschicht. Ein Magento Entwickler prüft das vor dem Kauf, nicht danach.
Wie der Umbau von Luma auf Hyvä als Gesamtprojekt abläuft, steht auf der Seite Magento Hyvä.
12
Wie bindet ein Magento Entwickler Schnittstellen an? REST, GraphQL und Warteschlangen
Schnittstellen sind der Bereich, in dem sich Qualität am deutlichsten zeigt. Fehler fallen dort oft erst nach Wochen auf. Ein Magento Entwickler denkt deshalb von Anfang an an Wiederholung, Protokoll und Rückmeldung.
REST
Eigene Endpunkte entstehen aus Service Contracts und werden in der Webapi-Konfiguration mit Berechtigung hinterlegt. Der Zugriff wird über ACL-Ressourcen gesteuert.
GraphQL
Sinnvoll, wenn ein Frontend oder eine App gezielt Felder abfragen soll. Wir erweitern das Schema um genau die Felder, die gebraucht werden, und lassen Resolver schlank.
Warteschlangen
Aufgaben, die nicht sofort fertig sein müssen, laufen asynchron über die Message Queue. Der Kunde im Checkout wartet nicht auf einen Export, der auch eine Minute später reichen würde.
Idempotenz
Eine Nachricht darf zweimal ankommen, ohne dass eine Bestellung doppelt im ERP landet. Dafür braucht jede Übergabe eine eindeutige Kennung.
Fehlerbehandlung
Fehlgeschlagene Läufe landen nicht still im Nichts. Sie werden protokolliert, wiederholt und, wenn nötig, an eine Person gemeldet.
Zugriffsschutz
Tokens und Schlüssel liegen in der Konfiguration oder in der Umgebung, nie im Repository.
Konkrete Anbindungen an Warenwirtschaft und PIM beschreibt die Seite Magento Schnittstellen. Für entkoppelte Frontends gibt es einen eigenen Überblick zu Headless.
13
Performance und Caching: Wo ein Magento Entwickler ansetzt
Ein langsamer Shop hat selten eine einzige Ursache. Bevor wir etwas ändern, messen wir: Welche Seite ist langsam, bei welchem Aufruf, mit welchem Cache-Zustand? Ohne diese Antwort optimiert man gern an der falschen Stelle.
Magento arbeitet mit mehreren Cache-Schichten, vom Konfigurations-Cache bis zum Full Page Cache. Ein häufiger Fehler in eigenem Code ist, einen Block nicht cachefähig zu machen, etwa weil er Kundendaten direkt ausgibt. Eine einzige solche Stelle kann die Zwischenspeicherung einer ganzen Seite aushebeln. Ein typisches Beispiel ist ein Hinweisbanner mit dem Namen des Kunden im Header. Kundenspezifische Inhalte gehören deshalb in private Daten, die der Browser nachlädt.
Auf der Datenbankseite lohnt der Blick auf Abfragen in Schleifen. Wer für jedes Produkt einer Liste einzeln nachlädt, erzeugt viele kleine Anfragen statt einer großen. Auch Indexer und Cron-Jobs gehören in die Betrachtung, denn sie laufen oft zu Zeiten, in denen niemand hinsieht.
Im Frontend zählt, wie viel JavaScript und CSS ausgeliefert wird. Hier zahlt sich Hyvä aus. Ein Überblick über Messwerte und Maßnahmen steht auf der Seite zur Magento Performance.
14
Code-Qualität: Welche Prüfungen ein Magento Entwickler einsetzt
Qualität beim Magento Entwickler ist kein Gefühl, sondern eine Reihe von Prüfungen, die vor jeder Übergabe laufen:
Werkzeug
Was geprüft wird
Nutzen für Dich
Coding Standards (PHPCS)
Stil, Namen, Struktur nach dem Magento-Regelwerk
Code, den auch andere lesen und weiterführen können
Statische Analyse (PHPStan)
Typen, Rückgabewerte, nicht vorhandene Methoden
Fehler fallen vor dem Live-Gang auf, nicht im Warenkorb
Unit-Tests
Einzelne Klassen mit eigener Logik
Geänderte Berechnungen lassen sich schnell gegenprüfen
Integrationstests
Zusammenspiel mit Datenbank und Magento
Ein Update bricht nicht unbemerkt eine Kernfunktion
Code Review
Lesbarkeit, Risiko, Abweichungen vom Ticket
Ein zweites Augenpaar vor dem Deployment
Nicht jeder Auftrag braucht jede Prüfung. Eine Preisberechnung mit vielen Sonderfällen verdient Tests, eine neue Textzeile im Template nicht. Wir legen im Angebot fest, was wir testen und warum.
15
Wie plant ein Magento Entwickler ein Upgrade auf eine neue Version?
Updates sind Pflege, kein Ausnahmeprojekt. Ein Magento Entwickler plant sie in vier Schritten:
01
Release-Hinweise lesen
Welche Änderungen betreffen Deine Module, Deine PHP-Version und Deine Suche?
02
Abhängigkeiten prüfen
Composer zeigt, welche Drittmodule noch nicht zur neuen Version passen.
03
Auf Staging durchspielen
Update, Kompilierung und ein Durchlauf der wichtigsten Abläufe, vom Warenkorb bis zur Bestellmail.
04
Live einspielen
Mit Wartungsmodus, Datensicherung und einem klaren Weg zurück, falls etwas nicht stimmt.
Der Abstand zwischen zwei Versionen entscheidet über den Aufwand: Kleine Schritte sind günstiger als ein Sprung über viele Versionen. Mehr dazu steht auf der Seite Magento Update. Wer von Magento 1 kommt, liest zusätzlich die Hinweise zur Migration.
16
Wie findet ein Magento Entwickler Fehler in fremdem Code?
Einen fremden Shop zu übernehmen heißt, zuerst zu verstehen. Ein Magento Entwickler geht dabei methodisch vor:
Fehler reproduzieren
Ohne einen Weg, das Problem auf Staging auszulösen, bleibt jede Korrektur eine Vermutung. Wir notieren Schritte, Daten und erwartetes Verhalten.
Protokolle lesen
Exception- und System-Log zeigen meist die Stelle, an der etwas schiefgeht. Wiederkehrende Meldungen sind oft wichtiger als die letzte.
Mit Xdebug nachvollziehen
Ein Haltepunkt zeigt, welche Plugins und Observer an einem Aufruf beteiligt sind. So findet man Eingriffe, die niemand mehr auf dem Schirm hatte.
Ursache statt Symptom beheben
Wird nur die Fehlermeldung unterdrückt, kommt das Problem zurück. Wir schreiben auf, was die Ursache war und wie sie behoben wurde.
Wenn der Shop gerade ausfällt, ist der Notfall-Support der schnellere Weg.
17
Was prüft ein Magento Entwickler bei Code-Audit und Sicherheit?
Ein Audit liest den vorhandenen Code, bevor jemand etwas ändert. Bei Sicherheitsthemen sehen wir uns besonders diese Stellen an:
Eigene Module
Werden Eingaben validiert und Ausgaben maskiert? Sind Endpunkte mit der richtigen Berechtigung versehen?
Drittmodule
Gibt es Updates, die seit langem fehlen? Wer pflegt das Modul noch?
Core-Änderungen
Liegen Änderungen an Magento-Dateien vor oder Patches, die nicht dokumentiert sind?
Admin-Zugänge
Gibt es Benutzer, die niemand mehr braucht, oder Rollen mit zu weitreichenden Rechten?
Konfiguration
Sind Schlüssel, Passwörter und Debug-Einstellungen so abgelegt, wie sie es sein sollten?
Patch-Stand
Sind die aktuellen Sicherheits-Patches der eingesetzten Version eingespielt?
Das Ergebnis ist eine nach Risiko sortierte Liste. Die Einzelheiten zum Vorgehen stehen auf der Seite Magento Code-Audit, Themen rund um Härtung auf der Seite Magento Sicherheit.
18
Was braucht ein Magento Entwickler von Dir, bevor es losgeht?
Mit wenigen Vorbereitungen startet ein Magento Entwickler schneller und rechnet weniger Einarbeitung ab:
Ziel in einem Satz
Was soll nach der Arbeit anders sein? Ein messbares Ziel hilft mehr als eine lange Wunschliste.
Zugang zum Repository
Mit eigenem Benutzer. Ohne Versionsverwaltung arbeiten wir nur ungern an Bestandscode.
Ein Staging-System
Eine Kopie des Shops, auf der gefahrlos getestet werden kann. Fehlt sie, richten wir sie als ersten Schritt ein.
Admin-Zugang
Mit einer Rolle, die zum Auftrag passt, nicht mit dem Hauptkonto.
Liste der Drittmodule
Einschließlich der Frage, welche davon wirklich genutzt werden.
Ansprechperson
Jemand, der Rückfragen zur Fachseite beantworten und Abnahmen entscheiden kann.
19
Wie ein gutes Ticket für einen Magento Entwickler aussieht
Ein Ticket für einen Magento Entwickler ist die Vereinbarung zwischen Dir und uns. Je genauer es beschrieben ist, desto weniger Rückfragen entstehen und desto verlässlicher wird die Schätzung. Ein gutes Ticket besteht aus wenigen Teilen.
Am Anfang steht die Ausgangslage: Was passiert heute, und wo? Danach folgt das gewünschte Verhalten in einfachen Worten. Wer es schafft, ein konkretes Beispiel zu nennen, etwa eine Bestellung mit einem bestimmten Produkt und einer bestimmten Kundengruppe, spart dem Magento Entwickler oft eine halbe Stunde Suche.
Am Ende stehen die Abnahmekriterien. Sie beantworten die Frage, woran Ihr erkennt, dass die Aufgabe erledigt ist. Dazu gehört auch, was ausdrücklich nicht Teil des Tickets ist. Screenshots, Fehlermeldungen und die betroffene Adresse gehören an dieselbe Stelle, nicht in drei verschiedene Nachrichten.
Kurzform
Ausgangslage, gewünschtes Verhalten, Beispiel, Abnahmekriterium und Abgrenzung. Fünf Punkte, die fast jede Aufgabe eindeutig machen.
20
Typische Aufwandsklassen bei der Arbeit mit einem Magento Entwickler
Wir nennen hier bewusst keine Stundenzahlen, weil sie vom Zustand Deines Shops abhängen. Die Einordnung hilft Dir trotzdem, Aufgaben zu sortieren:
Klasse
Typische Aufgabe
Was den Aufwand bestimmt
Klein
Konfiguration, Textänderung, kleine Anpassung im Template
Meist klar umrissen, schnell abzunehmen
Mittel
Ein Plugin, eine Admin-Einstellung, ein neues Feld mit Anzeige im Shop
Zahl der Stellen, an denen das Feld auftaucht
Groß
Eigenes Modul mit Datenbank, Admin-Bereich und Frontend
Umfang der Fachlogik und der Abstimmung
Integration
Anbindung an ERP, PIM oder Marktplatz
Qualität der Gegenseite und Zahl der Sonderfälle
Offen
Fehlersuche ohne bekannte Ursache
Erst die Analyse macht eine Schätzung möglich
Bei offenen Aufgaben vereinbaren wir zuerst ein Zeitkontingent für die Analyse und schätzen die Umsetzung danach. So bezahlst Du keine Annahmen, die sich später als falsch herausstellen.
21
Was bekommst Du vom Magento Entwickler bei der Übergabe?
Eine Arbeit ist erst fertig, wenn sie jemand anderes weiterführen kann. Deshalb gehört zu jeder Lieferung ein nachvollziehbarer Verlauf im Repository: Änderungen in kleinen, benannten Schritten statt in einem großen Paket.
Zusätzlich halten wir fest, was ein Magento Entwickler wissen muss, der morgen einsteigt. Das sind die Aufgabe des Moduls, die Einstellungen im Admin, abhängige Systeme, Cron-Jobs und bekannte Grenzen. Diese Notizen sind kurz, aber sie liegen dort, wo man sie sucht.
Bei jeder Übergabe zeigen wir Dir, wie das Neue im Admin bedient wird, und weisen auf Stellen hin, die später Pflege brauchen. Wenn Du danach selbst einen Entwickler im Haus hast oder einen anderen Anbieter beauftragst, findet dieser einen Stand vor, mit dem sich arbeiten lässt.
Bring Deine Aufgabe mit, wir kümmern uns um die Technik
Beschreibe kurz Dein Vorhaben oder Dein Problem. Im kostenlosen Erstgespräch klären wir, ob und wie wir helfen können.
Unser Stundensatz beträgt 30 Euro. Für wiederkehrenden Bedarf gibt es Wartungspakete ab 89 Euro im Monat. Größere Projekte kalkulieren wir nach einem Erstgespräch.
Wie finde ich heraus, ob ein Magento Entwickler gut ist?
Frag nach prüfbaren Arbeitsproben, nach dem Umgang mit Updates und Patches, nach Versionskontrolle und nach Code-Standards. Gute Entwickler beantworten das konkret und ohne Ausweichen.
Kann ein Magento Entwickler einen bestehenden Shop übernehmen?
Ja. Wir beginnen mit Zugriff, Bestandsaufnahme und, falls nötig, einem Code-Audit, bevor wir Änderungen vornehmen.
Arbeitet ihr mit Hyvä?
Ja, Hyvä ist unser Standard im Frontend, für neue Shops und für den Umbau von Luma. Mehr dazu auf der Seite Hyvä-Themes.
Wem gehört der Code, den ihr schreibt?
Rechte an individuell entwickeltem Code regeln wir im Angebot schriftlich, damit Du später frei entscheiden kannst, wer daran weiterarbeitet.
Übernehmt ihr auch dringende Fehlerbehebung?
Ja, für akute Ausfälle gibt es den Notfall-Support. Er wird ebenfalls zum Stundensatz abgerechnet.