Plattform statt Boilerplate: Welche Teile eines Kundenprojekts wiederverwendbar sein sollten

Fast jedes Softwarehaus hat ein internes Framework – und fast jedes hat schon eines beerdigt. Der Unterschied zwischen einer tragfähigen Basis und teurem Ballast liegt selten in der Technik. Er liegt im Schnitt: Was gehört hinein, was bleibt draußen, und wer entscheidet das?

1. Das immer gleiche Fundament

In jedem Business-Softwareprojekt tauchen dieselben Bausteine auf: Benutzerverwaltung, Rollen und Rechte, Mandanten- oder Organisationskontext, Stammdaten, Datenzugriff, Historie, Dateiablage, Reporting-Grundlagen, Auditierbarkeit. Fachlich interessiert sich kein Kunde dafür – bezahlen muss er es trotzdem, in jedem Projekt neu.

2. Das Schnittkriterium

Statt langer Diskussionen hilft eine einzige Frage:

„Ähnlich“ ist die Falle. Zwei Projekte brauchen beide eine Freigabelogik, aber mit unterschiedlichen Zuständen und Regeln. Wer das zusammenzieht, baut ein konfigurierbares Monster, das beide Projekte schlechter bedient als zwei eigene Implementierungen.

3. Was in die Basis gehört

• Identität, Rollen und Rechte. Fachlich immer gleich, sicherheitskritisch, teuer in der Eigenentwicklung.
• Mandanten- und Organisationskontext. Nachträglich extrem teuer, deshalb von Anfang an in der Basis.
• Datenzugriff und Modellierung. Einheitliche Muster für Entitäten, Relationen und Validierungen.
• Historie und Nachvollziehbarkeit. Fast immer gefordert, fast immer unterschätzt, siehe Audit Trails.
• Querschnittsthemen: Fehlerbehandlung, Protokollierung, Konfiguration, Internationalisierung.
• Delivery-Grundgerüst: Build, Container, Pipeline-Vorlagen.

4. Was draußen bleibt

• Fachlogik. Immer. Auch wenn zwei Kunden „fast dasselbe“ brauchen.
• Oberflächenspezifika jenseits eines gemeinsamen Gestaltungsrahmens.
• Integrationen zu Kundensystemen – jede ist anders, auch wenn das Zielsystem gleich heißt.
• Alles mit genau einem Nutzer. Ein Baustein für ein Projekt ist kein Baustein, sondern Code an der falschen Stelle.

5. Copy-Paste-Boilerplate und seine Kosten

Die verbreitetste Form der Wiederverwendung ist das Kopieren eines Projekt-Skeletts. Das ist am Tag eins die schnellste und über die Jahre die teuerste Variante:

• Ein Sicherheitsproblem muss in acht Projekten einzeln behoben werden.
• Verbesserungen fließen nicht zurück – jedes Projekt driftet weiter ab.
• Entwicklerwechsel zwischen Projekten wird teurer, weil sich alles „fast gleich“ anfühlt.
• Nachweise über einheitliche Qualitätsstandards sind nicht führbar.

Die Unterscheidung ist damit weniger technisch als organisatorisch: Boilerplate wird kopiert, eine Plattform wird referenziert und versioniert.

6. Versionierung und Migration

Eine Basis ohne Versionsdisziplin wird zum Klotz. Was funktioniert:

• Semantische Versionierung mit klarer Aussage, was eine brechende Änderung ist.
• Mehrere unterstützte Versionen gleichzeitig – Projekte können nicht alle gleichzeitig migrieren.
• Migrationsanleitungen je brechender Änderung, idealerweise mit automatisierter Umstellung.
• Ein Wartungsfenster pro Projekt fest einplanen; ohne reservierte Zeit passiert die Migration nie.
• Rückfluss organisieren: Was in einem Projekt entsteht und allgemein nützlich ist, wandert zurück in die Basis – mit Review.

7. Mandantenfähigkeit als Sonderfall

Mandantenfähigkeit ist der Punkt, an dem sich früh entscheidet, ob eine Basis langfristig trägt. Sie nachträglich einzuziehen bedeutet, jede Abfrage, jede Berechtigungsprüfung und jede Datenmigration anzufassen. Deshalb gehört sie in die Basis, auch wenn das erste Projekt nur einen Mandanten hat – vorausgesetzt, das Modell ist von Anfang an durchgängig und wird zentral durchgesetzt, nicht pro Abfrage.

8. Woran interne Frameworks scheitern

1. Kein Eigentümer. Eine Basis ohne verantwortliches Team wird zum Nebenprojekt und veraltet.
2. Zu früh verallgemeinert. Abstraktion nach dem ersten Projekt trifft fast immer die falsche Achse.
3. Zu viel drin. Wenn Fachlogik einzieht, wird jede Änderung zum Politikum.
4. Keine Migrationspfade. Projekte bleiben auf alten Ständen, die Basis zerfällt faktisch in Forks.
5. Keine Dokumentation. Was nicht beschrieben ist, wird umgangen – von Menschen wie von Agents.

9. Selbst bauen oder einsetzen

Eine eigene Basis lohnt sich, wenn genügend Projekte davon profitieren, ein Team sie dauerhaft verantworten kann und die Anforderungen so speziell sind, dass Standardlösungen nicht passen. Sie lohnt sich nicht, wenn sie neben dem Tagesgeschäft mitlaufen soll – dann entsteht eine Basis, die nie fertig und nie aktuell ist.

Genau an dieser Stelle setzt CodamAI an: als vorhandenes, gepflegtes Fundament für Daten, Identitäten, Rechte und Delivery, auf dem die Fachlogik individuell entsteht. Details auf der Feature-Seite, die wirtschaftliche Seite im Deep Dive KI für Softwarehäuser.

Checkliste: Basis richtig schneiden

Fazit

Wiederverwendung scheitert selten an der Technik und fast immer am Schnitt und am Eigentum. Wer die Basis auf das begrenzt, was wirklich identisch ist, sie versioniert statt kopiert und ihr ein verantwortliches Team gibt, bekommt genau den Effekt, den KI-Werkzeuge allein nicht liefern: weniger Arbeit, die überhaupt entsteht.

Das ist unspektakulär und wirkt langsam – aber es ist der einzige Hebel, der über Projekte hinweg zusammengesetzt statt jedes Mal neu gezogen wird.