Individuelle Entwicklung

Wenn kein fertiges Modul passt

Fertige Module lösen wiederkehrende Aufgaben. Die interessanten Probleme sind aber meistens die, die es nur bei einem Kunden gibt: ein ERP mit eigenen Regeln, ein gesetzlicher Nachweis vor dem Kauf, ein Prozess, den niemand sonst so fährt. Dafür bauen wir Module nach Maß — geplant nach deinen Anforderungen, nicht nach unserem Katalog — und dort, wo eine Erweiterung nicht mehr der richtige Ort ist, Middleware und eigenständige Anwendungen.

Woran wir arbeiten

Was hier steht, stammt aus laufenden Projekten — keine Leistungsliste, die wir für die Website erfunden haben.

Module nach Maß

Der häufigste Fall ist nicht der exotischste: Es gäbe fast ein passendes Modul — nur eben fast. Dann planen und bauen wir eines, das genau deinen Ablauf abbildet, statt drei Erweiterungen nebeneinander zu betreiben und die Lücken mit Workarounds zu schließen. Gebaut wird mit den Mitteln des Shopsystems: ohne Core-Eingriffe, updatefähig und dokumentiert, damit später auch jemand anderes damit arbeiten kann. Auf Wunsch mit eigener Backend-Oberfläche, Rechteverwaltung und Mehrsprachigkeit.

  • Magento 2
  • Shopware 6
  • WordPress / WooCommerce
  • Ohne Core-Eingriffe

Middleware zwischen Shop und Backend

ERP, Warenwirtschaft, PIM, CRM, Marktplätze: Sobald mehrere Systeme dieselben Daten anfassen, wird die direkte Kopplung zur Dauerbaustelle. Wir bauen einen eigenen Dienst dazwischen, der Formate übersetzt, Ausfälle abfängt, Aufträge puffert und jeden Vorgang nachvollziehbar protokolliert — statt dass ein Timeout im ERP den Checkout blockiert.

  • Laravel
  • Symfony
  • REST & GraphQL
  • Message Queues
  • Cronjobs

Eigenständige Anwendungen neben dem Shop

Nicht jede Logik gehört ins Shopsystem. Kalkulatoren, Konfiguratoren, Portale für Händler oder Auswertungen laufen besser als eigener Dienst, der per Schnittstelle angebunden ist. Das hält den Shop schlank, lässt sich unabhängig deployen und übersteht auch einen Versionssprung des Shopsystems.

  • Laravel
  • PHP 8
  • MySQL
  • Redis
  • Docker

Regulierte Produkte und Verkaufsbeschränkungen

Manche Produkte dürfen nur an Kunden verkauft werden, die eine Erlaubnis oder einen Sachkundenachweis vorgelegt haben. Wir bilden solche Regeln vollständig im Shop ab: geprüfte Nachweise mit Freigabedatum, produktbezogene Zuordnung, Prüfung beim Legen in den Warenkorb und verständliche Hinweise statt kommentarloser Fehlermeldungen. Für Shopware gibt es das inzwischen als fertiges Modul: Freigabepflichtige Produkte.

  • Magento 2
  • Shopware 6
  • Kundengruppen

Dokumente und wiederkehrende Abläufe

Rechnungen und Gutschriften automatisch erzeugen, archivieren und für Buchhaltung oder Kundenkonto bereitstellen. Ebenso Importe, Exporte, Feeds und Datenabgleiche, die zuverlässig laufen müssen — mit Protokollierung, die im Fehlerfall auch etwas aussagt.

  • PDF-Erzeugung
  • Import/Export
  • Logging & Monitoring

Bestehende Systeme übernehmen

Oft geht es nicht um Neubau, sondern um ein gewachsenes System, das seit Jahren läuft und dessen Entwickler nicht mehr erreichbar sind. Wir arbeiten uns ein, dokumentieren, bringen Abhängigkeiten auf einen aktuellen Stand und machen den Betrieb wieder planbar.

  • Code-Audit
  • Versionsupdates
  • Deployment

Ein Modul, das es so noch nicht gibt

Nicht jede Sonderanforderung braucht gleich eine eigene Anwendung. Sehr oft ist die richtige Antwort schlicht ein Modul — nur eben eines, das es fertig nicht gibt: dein Rabattmodell, deine Freigabelogik, dein Bestellprozess, deine Regeln für Versandkosten oder Mindestbestellmengen. Genau das planen und bauen wir, zugeschnitten auf deinen Ablauf statt auf den kleinsten gemeinsamen Nenner eines Marktplatz-Plugins.

Technisch gelten dabei dieselben Regeln wie für unsere Katalog-Module: keine Core-Eingriffe, saubere Erweiterungspunkte des jeweiligen Systems, kein externer Tracker, und eine Struktur, die ein Systemupdate übersteht. Was individuell ist, soll die Wartung nicht teurer machen als nötig.

Wie so ein Modul entsteht:

  • Anforderung gemeinsam durchsprechen — meist ist der beschriebene Wunsch nicht ganz das eigentliche Problem
  • Konzept mit Funktionsumfang, Backend-Oberfläche und Aufwandsschätzung, bevor Code entsteht
  • Umsetzung in Schritten, jeder Stand auf einer Testumgebung nachvollziehbar
  • Übergabe mit Dokumentation und Quellcode — das Modul gehört dir
  • Auf Wunsch Pflege und Anpassung bei künftigen Shop-Updates

Wenn sich unterwegs zeigt, dass eine Funktion auch für andere Shops taugt, wird daraus manchmal später ein Standardmodul. Dein individueller Teil bleibt davon unberührt — und Vorrang hat immer dein Anwendungsfall, nicht die Katalogtauglichkeit.

Warum eigene Middleware statt Direktanbindung?

Die schnellste Lösung ist fast immer, den Shop direkt mit dem Zielsystem sprechen zu lassen. Das funktioniert — bis das andere System langsam wird, ein Feld umbenennt oder für zwei Stunden nicht erreichbar ist. Dann steht der Checkout, und niemand weiß, welche Bestellung übertragen wurde und welche nicht.

Eine eigene Schicht dazwischen nimmt Vorgänge an, bestätigt sie sofort und arbeitet sie eigenständig ab. Fällt ein System aus, laufen die Aufträge in eine Warteschlange statt ins Leere. Ändert sich ein Format, wird das an einer Stelle angepasst statt an fünf. Und weil jeder Vorgang protokolliert wird, lässt sich im Zweifel belegen, was wann übergeben wurde.

Für solche Dienste setzen wir meistens auf Laravel — die Bausteine für Warteschlangen, geplante Aufgaben und Protokollierung sind dort bereits vorhanden, und das Ergebnis lässt sich unabhängig vom Shopsystem betreiben und aktualisieren. Wenn ein Projekt besser zu Symfony oder zu einem schlanken eigenen Dienst passt, machen wir das stattdessen.

Wie so ein Projekt abläuft

  • Bestandsaufnahme: Welche Systeme sind beteiligt, wo tut es aktuell weh?
  • Konzept mit klarer Aufwandsschätzung, bevor Code entsteht
  • Umsetzung in nachvollziehbaren Schritten, jeweils auf einer Testumgebung
  • Übergabe mit Dokumentation — auch für den Fall, dass jemand anderes weiterarbeitet

Und wenn das Shopsystem selbst das Problem ist?

Manchmal lohnt sich kein weiterer Umbau, weil die Grundlage nicht mehr trägt — etwa bei Magento 1 oder OpenMage ohne Sicherheitsupdates. Dann ist der Systemwechsel der ehrlichere Weg. Wie wir Umzüge abwickeln, steht unter Migration.

Klingt nach eurem Problem?

Beschreib kurz, welche Systeme beteiligt sind und woran es hakt. Wir sagen dir ehrlich, ob sich der Aufwand lohnt — auch wenn die Antwort „so nicht" lautet.

Projekt schildern