Zwei Jahre voller Unwägbarkeiten, ein Fundament, das sich nicht bewegt hat

Keine Entwicklung läuft wie geplant. Das ist kein Organisationsfehler, sondern liegt in der Natur der Arbeit: Über drei Jahre bewegt sich der Markt, Bibliotheken ändern ihre Lizenz, Frameworks bringen Hauptversionen heraus, das Team wechselt, und das Produkt selbst findet heraus, für wen es da ist. Die eigentliche Frage lautet also nicht „wie vermeidet man Unvorhergesehenes“, sondern was in einer Anwendung stehen bleiben muss, wenn sich alles andere bewegt.

Wir haben ein Lehrbeispiel zur Hand. BuyStep, der B2B-Marktplatz für Energie, dessen Plattform wir seit Sommer 2024 entwickeln, hat Framework, Datenbank, Mapping-Engine, E-Mail-Anbieter, Abrechnungssystem und Präsentationstechnik gewechselt. Zwei gekaufte Vorlagen wurden weggeworfen und die Migrationen viermal zurückgesetzt. Heute läuft die Plattform auf einer .NET-10-API und einem Next.js-16-Portal, und ihr Domänenmodell ist immer noch dasselbe wie im August 2024.

Für diesen Artikel haben wir nichts aus dem Gedächtnis rekonstruiert: Sechsundzwanzig echte Commits wurden aus der Git-Historie geholt, mit dem SDK ihrer Zeit neu kompiliert, gegen eine frische Datenbank gestartet und fotografiert. Fünfundzwanzig sind wieder angelaufen. Die Zahlen stammen aus Git, nicht aus einer Schätzung.

Drei Wochen, um das Fundament zu legen, zwei Jahre, um davon zu profitieren #

Das Repository beginnt am 1. August 2024. Was in den ersten zwanzig Tagen eingerichtet wird, bestimmt alles Weitere:

• Eine Schichtenarchitektur (Domain, Application, Infrastructure, WebApi, Utils), angelegt mit den ersten Commits, bevor es überhaupt etwas anzuzeigen gab.
• Ein generisches Übersetzungsmodell: eine Entität, eine zugehörige Übersetzungstabelle. Keine Spalten nom_fr, nom_en, keine pro Sprache duplizierten Ressourcendateien.
• Continuous Integration ab dem ersten Tag. Die Pipeline-Datei wird am selben Tag achtmal korrigiert, bevor sie läuft. Das ist mühsam, und es ist die beste Investition des Projekts: Zwei Jahre später blockiert diese Pipeline immer noch, was etwas kaputt macht.
• Datenbankmigrationen als Code, mit der Anwendung versioniert, statt eines Schemas, das irgendwo von Hand verwaltet wird.

Unwägbarkeit 1: die gekaufte Vorlage, zweimal weggeworfen #

Mit einer gekauften Vorlage zu starten, ist eine vernünftige Entscheidung für den Anfang: Sie verschafft Zeit. Sie kostet im Oktober 2024, als mehr als 240.000 Zeilen alter Präsentationsdateien gelöscht werden müssen, um sie durch ein schlankeres Stylesheet zu ersetzen. Und sie kostet erneut im Januar 2025, als eine zweite Vorlage am Stück importiert wird, während die alte Seite unter einem Namen mit OLD daneben erhalten bleibt.

Der wichtige Punkt: Beide Aufräumaktionen betrafen nur die Präsentationsschicht. Keine Entität, kein Anwendungsdienst, keine Migration war betroffen. Ein Projekt, in dem die gekaufte Vorlage bis ins Datenmodell durchgesickert wäre, hätte diese beiden Episoden mit einer Neuentwicklung bezahlt.

Unwägbarkeit 2: die Migrationen, viermal zurückgesetzt #

Das ist das sichtbarste Symptom eines jungen Projekts: Die Historie der Datenbankmigrationen wird viermal neu aufgesetzt. Im Dezember 2024 verschwinden die meisten Dateien aus Oktober und November. Im März 2025 ersetzen dreizehn neue Migrationen die vorherigen. Im Oktober 2025 werden 54 Dateien auf einen Schlag gelöscht. Im April 2026 wird die gesamte Historie zu einer einzigen Anfangsmigration zusammengefasst.

Ist das bedenklich? Solange das Schema aus dem Modell im Code abgeleitet wird und nicht umgekehrt, nein: Ein Zurücksetzen ist eine Hygienemaßnahme, kein Verlust. Schlimm wäre es, ein Schema zurückzusetzen, dessen maßgebliche Definition in der Produktionsdatenbank liegt und nirgends sonst.

Unwägbarkeit 3: Abhängigkeiten, die plötzlich ihre Bedingungen ändern #

Keine dieser Entscheidungen stand im ursprünglichen Plan, und jede wurde von außen erzwungen:

• Der Such-Client wechselt im Juni 2025 von einer aufgegebenen Bibliothek zur offiziellen Bibliothek, eine komplette API-Umstellung, durchgeführt in einem eigenen Zweig.
• Die Mapping-Bibliothek wird kostenpflichtig und prüft beim Start ein Token. Im April 2026 wird sie durch einen Codegenerator ersetzt, der dieselben Umwandlungen zur Kompilierzeit erzeugt: keine Reflection zur Laufzeit mehr, keine Lizenz mehr zu verlängern.
• Die API-Dokumentation gibt das bisherige Werkzeug zugunsten des nativen OpenAPI des Frameworks auf, nach einem Hin und Her, das noch am selben Tag zurückgenommen wurde.
• Der E-Mail-Versand wechselt im Dezember 2025 den Anbieter; die Dateiablage zieht im April 2026 in einen S3-kompatiblen Objektspeicher mit CDN; die eigene Abrechnung (Rechnungen, Überweisungen, Zahlungsdetails) wird im September 2025 zugunsten eines Modells gestrichen, das vollständig an den Zahlungsdienstleister ausgelagert ist.

Der rote Faden ist immer derselbe: Diese Bibliotheken waren auf die Infrastructure-Schicht beschränkt. Man ersetzt einen Adapter, kein System. An dem Tag, an dem ein Mapper kostenpflichtig wird, schreibt das Team, das dessen Aufrufe bis in die Fachdienste hat wandern lassen, dreihundert Dateien neu; das Team, das sie hinter einer Schnittstelle gehalten hat, zehn.

Unwägbarkeit 4: das Versions-Upgrade, das nicht gelingt #

März 2025, Wechsel von .NET 8 auf .NET 9. Auf dem Papier Routine: jede Projektdatei, jedes Paket der Datenzugriffsschicht, die Testsuite. In der Praxis ist es die arbeitsreichste Phase des ersten Jahres, achtundvierzig Commits, davon dreiundzwanzig zwischen 22 und 6 Uhr, und die einzige, deren Stand wir nie wieder zum Laufen gebracht haben.

Ein Jahr später dauert dieselbe Operation auf .NET 10 einen Tag, mitten in einem viel größeren Umbau. Nicht das Framework ist leichter geworden: Das Projekt hatte inzwischen Tests, eine Pipeline, eine Konfiguration über Umgebungsvariablen und ein reproduzierbares Container-Image.

Unwägbarkeit 5: die Arbeit, die man nicht sieht und trotzdem finanzieren muss #

Diese Episode ist kein Einzelfall. September 2024: ein ganzer Monat Domänenmodellierung (REST-API, DTO, erste Tests) ohne ein einziges geändertes Pixel. 3. Dezember 2025: zwölf Commits an einem Tag (Pipeline, Telemetrie, Provisionsverwaltung) und Screenshots, die exakt denen vom Vortag gleichen.

Das ist die häufigste Quelle von Missverständnissen zwischen einem technischen Team und denen, die seine Arbeit finanzieren. Was man sieht und was kostet, hängt nicht zusammen, und eine Projektsteuerung, die nur auf Bildschirme schaut, entscheidet am Ende immer gegen das Fundament, also gegen die Fähigkeit des Produkts, die nächste Unwägbarkeit aufzufangen.

Unwägbarkeit 6: das Team, das wechselt #

Die Historie verzeichnet bis zu vier aktive Mitwirkende in einem Monat und ganze Monate mit nur einem. Der Februar 2026 enthält nur einen Commit und eine Textkorrektur. Umgekehrt wird der Oktober 2025 von einer einzigen Person geschrieben, in elf aufeinanderfolgenden Merges in die Produktion.

Was diese Schwankung auffängt, ist kein Heldentum, sondern schriftlich festgehaltene Konventionen. Im Oktober 2025 wird die Konfiguration vollständig auf Umgebungsvariablen umgestellt, die Anwendung dockerisiert, ein Seed-Datensatz geschrieben, und die Build-Befehle werden im Repository dokumentiert. Ab da kann ein Neuzugang das Projekt zum Laufen bringen, ohne jemanden zu fragen. Das ist die einzige dauerhafte Antwort auf Fluktuation und nebenbei die Voraussetzung dafür, dass KI-Unterstützung nützt statt zu stören.

Was das Fundament ermöglicht hat: den halben Stack in drei Wochen ersetzen #

Zwischen dem 24. März und dem 12. April 2026 wird das Repository zu einem Monorepo umgebaut, die Datenbank wechselt von MySQL zu PostgreSQL (wobei die beiden getrennten Datenbanken wieder zu einer zusammengeführt werden), das Framework wird auf .NET 10 angehoben, das Portal wird in Next.js neu geschrieben und die Blazor-Administration aus dem Repository gelöscht. Drei Wochen.

Keiner dieser Schritte erforderte, die Fachdomäne neu zu schreiben. Genau das soll eine Schichtenarchitektur erkaufen, und unter realen Bedingungen wird das selten überprüft: Hier geschah es viermal hintereinander. Ein Detail, das alles sagt: Am Tag vor dem Löschen der Blazor-Administration korrigierten Commits noch ihre Navigation. Bis zum Schluss wird repariert, was ohnehin entfernt wird, weil das Entfernen geplant und datiert ist und keine doppelte Wartung nach sich zieht.

Was die Disziplin ersetzt hat: ausführbare Schutzmechanismen #

Ein Fundament hält nicht von allein; es hält, weil bei jeder Auslieferung etwas prüft, dass es hält. Im selben Zeitraum, in dem die Codemenge explodierte, kamen vier Dinge hinzu:

1. Die Integrationstests verlassen die In-Memory-Datenbank zugunsten eines echten, kurzlebigen PostgreSQL im Container, das zwischen den Tests zurückgesetzt wird. Eine In-Memory-Datenbank führt weder die Migrationen noch das datenbankspezifische SQL aus: Sie verdeckt genau die Fehler, die eine massive Migration erzeugt.
2. Architekturtests prüfen automatisch, dass die Schichten nicht übersprungen werden. Nur so bleibt ein Fundament ein Fundament, wenn fünfzehn Personen (oder fünfzehn Assistentensitzungen) darin schreiben.
3. Eine klare Trennung zwischen Unit-Tests (einige Sekunden) und Integrationstests (einige Dutzend Sekunden), damit niemand einen Grund hat, die ersten zu überspringen.
4. Eine fünfstufige Pipeline, die alles blockiert, was etwas kaputt macht, und im August 2026 hinzugekommene End-to-End-Tests für den Zahlungsablauf, dort, wo ein Fehler echtes Geld kostet.

Der ehrlichste Test: Können Sie Ihr Projekt von vor sechs Monaten nachbauen? #

Diese Frage hat die Rückschau am Ende gestellt, und wir nutzen sie inzwischen für unsere eigenen Audits. Einen alten Commit nachbauen, seine Migrationen anwenden, ihn starten: Wenn das scheitert, liegt es fast nie am Code. Es ist ein Secret, das Pflicht geworden ist, ohne dokumentiert zu sein, eine Abhängigkeit, die den Prozess anhält, wenn ihr Dienst fehlt, ein belegter Port, eine Migration, die sich nicht nachspielen lässt.

Mit anderen Worten: Es ist ein Test, ob man seine Umgebung beherrscht, und er ist gnadenlos. Die Werkzeuge, die ihn ausführen, sind in einem eigenen Artikel beschrieben; was die KI-Unterstützung bei der Durchführung dieser Migrationen geändert hat, in diesem hier.

Was wir daraus mitnehmen #

• Entscheiden Sie früh, was sich nicht bewegen wird. Schichtenaufteilung und Datenmodell kosten am Anfang oder später das Zehnfache. Alles andere ist ersetzbar und wird ersetzt werden.
• Kapseln Sie externe Abhängigkeiten. Eine Bibliothek, die Lizenz oder API ändert, darf nie mehr kosten als den Austausch eines Adapters.
• Ein aus dem Code abgeleitetes Schema lässt sich reparieren; einem von Hand verwalteten Schema ist man ausgeliefert. Aus diesem Grund haben vier zurückgesetzte Migrationshistorien nichts kaputt gemacht.
• Finanzieren Sie, was man nicht sieht. Die Monate ohne ein geändertes Pixel sind oft die prägendsten.
• Machen Sie das Projekt ohne Sie startbar. Konfiguration über Umgebungsvariablen, Container, Seed-Daten, dokumentierte Befehle: Das ist die Antwort auf den Weggang eines Entwicklers wie auf die Ankunft eines neuen.
• Automatisieren Sie die Prüfung des Fundaments. Tests gegen eine echte Datenbank, Architekturtests, eine blockierende Pipeline: Ohne sie verfällt ein Fundament unbemerkt.

So konzipieren wir die Geschäftsanwendungen, die wir entwickeln, und so übernehmen wir bestehende. Wenn Ihre Plattform ein paar Jahre alt ist, niemand sie mehr nachbauen kann und jede Weiterentwicklung teurer ist als die vorige, ist das genau die Diagnose, die wir stellen können. Erstgespräch kostenlos, Angebot binnen 48 Stunden und auf Wunsch Hosting in Frankreich.