Saubere Software-Architektur bei TBSoft: native Entwicklung, kaum Drittpakete

In der Software­branche ist „Schnell zusammen­klicken“ zur Disziplin geworden — schnelles Onboarding eines Drittpakets, schnelles Deployment, schnelles Update. Schnell ist nicht falsch. Aber in der Baustoff- und Zulieferer­industrie zählt etwas anderes: dass die Software in zehn Jahren noch zuverlässig läuft, dass ein Sicherheits­problem irgendwo in der Tiefe der Dependency-Kette nicht das ganze Werk lahmlegt, und dass Performance an der Waage und in der Disposition keine Glücks­sache ist.

Wir bei TBSoft entwickeln deshalb anders. Nativ. Mit wenigen bis keinen Drittpaketen. Dieser Beitrag erklärt, warum.

Was „nativ“ bei TBSoft bedeutet

Native Entwicklung heißt für uns: jede zentrale Funktion entsteht im Haus, in der Sprache und auf der Plattform, die für die jeweilige Aufgabe optimal ist — und nicht durch eine Schicht aus Wrappern, Frameworks und Convenience-Bibliotheken, die uns und unseren Kunden Verständnis und Kontrolle nehmen würden.

• memory
  Plattform-Nah statt Framework-Folklore

  Wir bauen auf den nativen APIs der jeweiligen Plattform auf — schnellere Ausführung, weniger Overhead, deterministisches Verhalten unter Last.

• verified_user
  Sicherheit durch Übersicht

  Jede Codezeile ist von uns nachvollziehbar. Keine fremden Pakete, die irgendwann gehackt werden oder ihre Lizenz ändern. Keine Supply-Chain-Überraschungen.

• speed
  Performance ist eingebaut, nicht aufgesetzt

  Wir profilieren regelmäßig auf der echten Hardware unserer Kunden — vom Werks­terminal bis zum Disponenten-PC. Geschwindigkeit ist kein Marketing-Versprechen, sondern eine Engineering-Disziplin.

• lock
  Wartbarkeit über Jahrzehnte

  Was wir heute schreiben, soll auch in 15 Jahren noch sauber updatebar sein. Native Strukturen altern langsamer als Framework-Stacks der jeweils letzten Mode.

Drittpakete: bewusst sparsam

Wir verwenden Drittpakete — aber sparsam, gezielt und nach klaren Kriterien. Jedes externe Paket ist eine Wette darauf, dass jemand anderes unsere Qualitäts­standards einhält, unsere Sicherheits­anforderungen ernst nimmt und in zehn Jahren noch verfügbar ist. Diese Wette gehen wir nur ein, wenn der Mehrwert hoch ist und die Alternative — Eigen­entwicklung — unverhältnismäßig wäre.

Was unsere Kunden davon haben

Die Argumentation klingt nach Engineering-Pedanterie. Praktisch zahlt sie aber direkt auf den Werks­alltag ein.

Performance ist kein Marketing-Wort

Software­performance ist ein wiederkehrendes Thema bei Werks­leitern. Die Waage soll antworten, die Disposition soll flüssig laufen, das Terminal in der Selbst­bedienung darf nicht hängen — gerade nachts, wenn niemand im Werks­büro sitzt. Native Entwicklung gibt uns die Kontrolle über jeden Millisekunden-Anteil im Code­pfad.

Konkret heißt das: wenn ein Kunde berichtet, dass eine Aktion zu lange dauert, können wir den Stack vom Klick bis zur Datenbank durch­leuchten — ohne uns durch fremde Pakete und ihre Eigenheiten kämpfen zu müssen. Das macht Performance-Optimierung zu einer plan­baren Disziplin, nicht zu einer Glaubens­frage.

Und die moderne Welt?

Natürlich beobachten wir, was sich in der modernen Software-Welt tut. KI-gestützte Optimierungen, neue Schnitt­stellen­standards, geänderte Browser-Engines, neue Plattformen. Aber wir adaptieren mit Augenmaß — und zuerst dort, wo unsere Kunden den größten Nutzen daraus ziehen.

Modern heißt nicht beliebig. Wir nehmen Neues auf, wenn es sich bewährt hat. Was sich nicht bewährt, lassen wir liegen — und ersparen unseren Kunden die Erfahrung.

Das ist der Unterschied zwischen Engineering und Mode. Und die Software, die Sie morgen früh an Ihrer Werks­waage starten, lebt von dieser Unterscheidung.