Deutsche Gründlichkeit. Kaufmännischer Anspruch.

CT4M steht für Handelswerkzeuge für Händler.

Wir entwickeln Tools für PrestaShop mit einer recht einfachen Idee dahinter: Software für Händler soll Geschäftsprobleme lösen und nicht neue technische Probleme schaffen.

CT4M entstand aus unserer eigenen Erfahrung im E-Commerce. Viele unserer Tools entstanden aus einem realen Problem im alltäglichen Geschäftsbetrieb – etwas, das zu viel Zeit in Anspruch nahm, zu viele manuelle Schritte erforderte oder von der verfügbaren Software einfach nicht gut abgedeckt wurde.

Also haben wir es gebaut.

Und weil wir in Düsseldorf, Deutschland, ansässig sind, geben wir gerne zu, eine gewisse Schwäche dafür zu haben, Dinge gründlich zu erledigen.

Nicht etwa, weil Software kompliziert sein müsste. Ganz im Gegenteil.

Gute Software sollte komplizierte Dinge vereinfachen.

Konzipiert für Unternehmen. Nicht für Programmierkenntnisse.

Unser Ausgangspunkt ist selten ein technisches Merkmal.

Es handelt sich üblicherweise um eine Frage wie:

Warum machen wir das manuell?

Warum kann PrestaShop uns diese Informationen nicht anzeigen?

Warum sind für diesen Prozess sechs Schritte nötig, wenn er doch nur zwei benötigen sollte?

Von dort aus arbeiten wir uns rückwärts zur Technologie vor.

Diese Händlerperspektive ist uns wichtig. Ein technisch beeindruckendes Modul, das die tägliche Arbeit nur verkompliziert, hat seinen Zweck verfehlt.

Unsere Werkzeuge sollen Zeit sparen, Fehler verhindern, nützliche Informationen liefern oder einen Prozess spürbar vereinfachen.

Am besten alle vier.

KI-gestützt. Von Menschen gesteuert.

Wir nutzen moderne KI-gestützte Entwicklung umfassend.

Spezialisierte Entwicklungs- und Überprüfungsagenten helfen uns, große Codebasen zu analysieren, Abhängigkeiten zu untersuchen, Grenzfälle zu testen und Änderungen in einer Geschwindigkeit zu überprüfen, die mit traditionellen Entwicklungsabläufen allein schwer zu erreichen gewesen wäre.

Aber Geschwindigkeit ist nicht das Ziel.

Bessere Software ist das Ziel.

Architektur, Anforderungen, Sicherheitsentscheidungen und die Freigabe von Produkten bleiben in menschlicher Hand. Wir nutzen KI, um mehr zu untersuchen, mehr zu testen und mehr zu erkennen – nicht als Ausrede, den Standard unserer Produkte zu senken.

Wir verzögern lieber eine Veröffentlichung, als ein fehlerhaftes Produkt auszuliefern.

Die Software, die in einem Online-Shop zum Einsatz kommt, verdient Respekt.

Ein PrestaShop-Modul kann auf Bestellungen, Kundendaten, Zahlungen, Datenbanken und geschäftskritische Prozesse zugreifen. Ein kleiner Programmierfehler kann daher weitreichende Folgen haben, die weit über das Modul selbst hinausgehen.

Wir sind der Ansicht, dass “es funktioniert in unserer Testumgebung” kein ausreichender Qualitätsstandard ist.

Bevor ein CT4M-Produkt auf den Markt kommt, wollen wir verstehen, was es verändert, wovon es abhängt und was schiefgehen könnte.

Das schließt auch die langweiligen Dinge mit ein.

Vor allem die langweiligen Dinge.

Unsere Standards

Unser Ziel ist es, CT4M-Module so zu entwickeln, dass sie sich nahtlos in eine PrestaShop-Installation einfügen.

Das bedeutet, Änderungen so weit wie möglich zu isolieren und dabei die etablierten APIs, Hooks und Erweiterungsmechanismen von PrestaShop zu nutzen. Überschreibungen nach Möglichkeit vermeiden. Wir verändern keine PrestaShop-Kerndateien.

Ein CT4M-Modul sollte nicht davon ausgehen, dass es das einzige Modul im Shop ist. Daher achten wir besonders auf die Interaktionen mit anderen Modulen, bestehenden Hooks, Datenbankstrukturen und dem normalen Verhalten von PrestaShop.

Sicherheit wird als integraler Bestandteil der Entwicklung betrachtet und nicht erst kurz vor der Veröffentlichung hinzugefügt. Je nach Modul umfasst dies Berechtigungs- und Authentifizierungsprüfungen, CSRF-Schutz, Validierung und Bereinigung von Eingaben, sicheren Datenbankzugriff, kontrollierte Dateiverarbeitung sowie den sorgfältigen Umgang mit Anmeldeinformationen und sensiblen Daten.

Wir testen auch mit den PrestaShop- und PHP-Versionen, für die wir explizit Kompatibilität deklarieren. Wir bevorzugen einen klar definierten Kompatibilitätsbereich, den wir tatsächlich getestet haben, gegenüber einer beruhigend klingenden Behauptung, die wir nicht belegen können.

Und wenn sich PrestaShop ändert, passen wir unsere Module lieber gleich an, anstatt diese Änderungen mit immer fragileren Modifikationen zu umgehen.

Unser Ziel ist klar:

Sicherer Code. Reibungslose Integration. Vorhersehbares Verhalten. Minimale Beeinträchtigung des restlichen Shopbetriebs.

Oder, um es etwas traditioneller auszudrücken:

Wenn wir es schon bauen, dann wollen wir es auch richtig bauen.