Maßgeschneiderte Softwareentwicklung

Nicht alles passt in eine Plattform. Wenn die Aufgabe ein eigener Service ist, eine Integrationsschicht, ein internes Tool oder ein Marketplace-Backend, bauen wir sie von Grund auf in TypeScript: mit schriftlich fixiertem Umfang, geliefert in Ihrem Repository und so dokumentiert, dass jedes fähige Team nach uns übernehmen kann.

Was wir bauen

• Eigene Integrationen zwischen E-Commerce und ERP / PIM / WMS, wenn der fertige Connector den Großteil des Ablaufs abdeckt und das, was er auslässt, genau der Teil ist, von dem Ihr Geschäft abhängt
• Interne Tools, die nicht in den Shop-Admin gehören: Pricing-Engines, Retourenabwicklung, Lager-Dashboards, Kundenservice-Konsolen
• Marketplaces, Multi-Tenant-SaaS-Backends und domänenspezifische Services, bei denen die Domänenlogik das Produkt ist
• Ablösung von Legacy-Eigenentwicklungen, deren Anforderungen zur Hälfte dokumentiert und zur anderen Hälfte mündlich überliefert sind. Das erste Deliverable ist dann, aufzuschreiben, was das alte System wirklich tut

Einige Projekte dieser Art aus den zehn Jahren E-Commerce-Engineering, auf denen diese Praxis steht, anonymisiert: eine automatische Repricing-Engine für einen Katalog mit 123.000 Produkten, gesteuert über die aus ERP-Daten vorhergesagte Zeit bis zum Ausverkauf, mit Regelbändern, einem Audit-Trail und definierten Grenzen für die Fälle, in denen automatische Regeln und menschliche Einschätzung voneinander abweichen. Ein weiteres war eine Neuberechnung der Verkaufshistorie, die durch Parallelisierung von 14 auf 2,5 Stunden verkürzt wurde. Zuletzt verkaufte Produkte werden dabei zuerst verarbeitet, damit die aktuellsten Zahlen als Erste vorliegen. Das dritte war eine Kundenmigration zwischen Plattformen ganz ohne Passwort-Reset-Mail: Beim ersten Login wird gegen den Legacy-Hash verifiziert und transparent ins neue Format gehasht, ein Klartext-Passwort wird zu keinem Zeitpunkt gespeichert.

Wie wir bauen

Jedes Backend, das wir liefern, folgt derselben Grundstruktur:

• Strukturierte Module mit expliziten Abhängigkeitsdeklarationen
• Dependency Injection, die sich für Tests und einzelne Umgebungen überschreiben lässt
• Lifecycle-Hooks, damit Subsysteme in der richtigen Reihenfolge starten und stoppen
• Vertragsprüfung beim Boot: Ist die Verdrahtung unvollständig, bricht die Anwendung den Start ab. Fehlkonfigurationen zeigen sich in Sekunden beim Boot, nicht als TypeError auf einer undefinierten Abhängigkeit drei Wochen nach Produktivsetzung.

Auf dieser Struktur bestehen wir, weil sie die Annahmen des Codes sichtbar hält und weil wir Software wollen, die auch ein Jahr nach dem Launch noch verständlich ist.

Wie wir liefern

• Die Arbeit findet in Ihrem Repository, in Ihrer Organisation statt, und mit der Zahlung erhalten Sie ein ausschließliches Nutzungsrecht an Code, Konfiguration und Dokumentation, die Sie bezahlt haben
• Tests und Vertragsprüfungen laufen ab der ersten Woche in der CI, nicht erst als Härtungsphase am Ende
• Wir liefern so aus, dass sich eine neue Version zurückrollen lässt, und das System kommt mit fertig verdrahteten Logs, Metriken und Alerts. Wie wir betreiben, was wir bauen, steht unter DevOps & Infrastruktur
• Übergabedokumentation ist bei uns ein festes Deliverable: Runbooks, eine Architektur-Notiz und ein Entscheidungslog

Liegt die eigentliche Schwierigkeit darin, zu entscheiden, was gebaut werden soll, statt es zu bauen, ist das Systemdesign & Architektur. Beides machen wir zusammen oder getrennt. Jede Umsetzung hat einen Festpreis, der vor Beginn der Arbeit schriftlich feststeht. Langlebige Systeme laufen danach meist als monatlicher Retainer weiter.