Die Greenfield-Falle: wenn das Fundament das Budget frisst

Greenfield klingt nach Freiheit: leeres Feld, keine Altlasten, alles neu. In der Praxis heißt es zuerst, dass nichts da ist. Kein Cluster, keine Pipeline, kein Terraform-State, keine Datenbank-Migration, keine Secrets. Dieser Artikel geht der Frage nach, warum genau dieser Teil eines Projekts so zuverlässig unterschätzt wird, warum er sich beim Bauen trotzdem gut anfühlt, und in welcher Reihenfolge man ihn angeht, damit am Ende ein Produkt steht und nicht nur ein Fundament.

Inhalt

• Sechs Wochen bis zum Termin, drei davon im Maschinenraum
• Was auf dem grünen Feld wirklich fehlt
• Warum die Schätzung für das Fundament zu klein ausfällt
• Warum sich Fundament-Arbeit nach Fortschritt anfühlt
• Zeit bis zum ersten Mehrwert
• Der Durchstich zuerst: das Walking Skeleton
• Was am ersten Tag stehen muss und was warten kann
• Wie dünn darf ein Fundament sein?
• Die drei Entscheidungen, die alles andere nach sich ziehen
• Was passiert, wenn das Fundament später nachgezogen wird
• Wo Vela Atlas ansetzt
• FAQ
• Fazit
• Quellen

Sechs Wochen bis zum Termin, drei davon im Maschinenraum

Die Szene wiederholt sich in fast jedem Projektstart. Ein Team bekommt sechs Wochen bis zum ersten vorzeigbaren Stand. Das Repository ist leer, die Fachlichkeit ist geklärt, die Motivation ist hoch. Nach drei Wochen läuft ein Cluster, die Pipeline ist grün, das Terraform-Modul ist sauber geschnitten. Fachlogik gibt es noch keine.

Niemand hat dabei gebummelt. Jede dieser drei Wochen war mit echter, notwendiger Arbeit gefüllt. Das Problem entsteht nicht durch schlechte Arbeit, sondern dadurch, dass diese Arbeit im Plan nie mit ihrem tatsächlichen Umfang aufgetaucht ist.

Beim Statusbericht steht dann ein Satz, den jeder kennt: die Infrastruktur steht, jetzt geht es richtig los. Für den Auftraggeber liest sich das wie ein halbes Projekt ohne sichtbares Ergebnis. Und die Hälfte des Budgets ist weg.

Was auf dem grünen Feld wirklich fehlt

„Setup“ ist im Plan meistens eine Zeile. Aufgeklappt sieht dieselbe Zeile so aus:

• Cloud-Account, Organisation, Projekte oder Konten je Stage
• Identitäten und Rechte: wer darf deployen, wie authentifiziert sich die Pipeline ohne dauerhafte Schlüssel
• Netzwerk: VPC, Subnetze, ausgehender Verkehr, private Erreichbarkeit der Datenbank
• Kubernetes-Cluster, Node-Pools, Autoscaling, Ressourcen-Grenzen
• Container-Registry samt Authentifizierung aus der Pipeline und aus dem Cluster
• DNS und Zertifikate, inklusive automatischer Erneuerung
• Ingress oder Gateway, dazu die Frage, was von außen überhaupt erreichbar ist
• Secrets: wo liegen sie, wie kommen sie in den Pod, wie werden sie rotiert
• Datenbank, Benutzer, Rechte, Backups und ein Migrationswerkzeug mit erster Baseline
• Deployment-Beschreibung, also Helm-Charts oder vergleichbares, je Stage konfigurierbar
• CI/CD: Build, Test, Image bauen, signieren, ausrollen, und das für jede Stage
• Logging, Metriken, ein Health-Endpunkt, der etwas Belastbares aussagt
• Lokale Entwicklungsumgebung, die dem Zielbild nahe genug kommt

Das sind über ein Dutzend Themen, von denen jedes einzelne eine Entscheidung, eine Umsetzung und einen Test braucht. Keines davon ist schwer. In Summe sind sie trotzdem Wochen.

Wichtiger als die Länge der Liste ist ihre Eigenschaft: Nichts darauf unterscheidet dein Produkt vom Wettbewerb. Der Nutzer bezahlt nicht für den Ingress. Er bezahlt für das, was danach kommt.

Warum die Schätzung für das Fundament zu klein ausfällt

Drei Mechanismen wirken hier zusammen, und alle drei ziehen in dieselbe Richtung.

Zuerst wird das Fundament als eine Position geschätzt, obwohl es ein Bündel ist. Die Zeile „Infrastruktur aufsetzen“ wird gefühlsmäßig bewertet, als Erinnerung an das letzte Mal. Geschätzt wird damit die Erinnerung an den Normalfall und nicht die Summe der Einzelteile. Wer die Liste oben Zeile für Zeile schätzt, kommt regelmäßig auf ein Vielfaches.

Dazu kommt, dass jede Entscheidung Folgeentscheidungen nach sich zieht. Die Wahl des Ingress bestimmt, wie Zertifikate ausgestellt werden. Das bestimmt, ob DNS automatisiert werden muss. Das bestimmt, wer Schreibrechte auf die Zone braucht. Solche Ketten sind beim Schätzen unsichtbar, weil man dabei immer nur den ersten Schritt sieht.

Und „fertig“ heißt beim Fundament etwas anderes als beim Feature. Ein Feature ist fertig, wenn es funktioniert. Ein Stück Infrastruktur ist erst fertig, wenn es reproduzierbar, in allen Stages gleich und auch nach einem Neuaufbau noch da ist. Der Abstand zwischen „läuft bei mir im Cluster“ und „läuft nach terraform destroy und terraform apply wieder genauso“ ist oft der größere Teil der Arbeit.

Dazu kommt ein vierter Punkt, der schwerer zu greifen ist. Auf dem grünen Feld gibt es keine Ausrede, es nicht richtig zu machen. In einem Bestandssystem hindern dich Altlasten. Am Anfang hindert dich nichts, und genau das ist die Einladung, den Umfang wachsen zu lassen.

Warum sich Fundament-Arbeit nach Fortschritt anfühlt

Diese Arbeit hat eine Eigenschaft, die Fachlogik nicht hat: sie gibt sofort Rückmeldung. Ein terraform apply läuft durch oder nicht. Ein Pod wird Ready oder nicht. Eine Pipeline ist grün oder rot. Jeder dieser Momente fühlt sich wie ein abgeschlossenes Stück Arbeit an.

Fachlogik gibt diese Rückmeldung nicht. Ob die Preisberechnung fachlich richtig ist, weiß nach zwei Stunden niemand sicher. Das ist unbefriedigender, und deshalb ist der Sog Richtung Maschinenraum real, gerade bei erfahrenen Entwicklern.

Dazu kommt der Wunsch, es diesmal besser zu machen. Man kennt die Stellen, die im letzten Projekt weh getan haben, und will sie diesmal von Anfang an sauber lösen. Das ist ein guter Instinkt. Er wird nur dann teuer, wenn er auf ein Projekt trifft, das noch keine einzige Zeile Fachlichkeit ausgeliefert hat, denn dann optimierst du für Probleme, die dein Produkt noch gar nicht hat.

Die ehrliche Prüffrage in dieser Phase lautet: Löse ich gerade ein Problem, das wir heute haben, oder eines, das wir im letzten Projekt hatten?

Zeit bis zum ersten Mehrwert

Die meisten Projekte messen Fortschritt an erledigten Tickets. Diese Zahl steigt in den ersten Wochen zuverlässig, auch wenn der Nutzer davon nichts hat. Eine ehrlichere Frage ist: Wie viele Tage liegen zwischen dem ersten Commit und dem Moment, in dem ein echter Anwender etwas tun kann, das ihm nützt?

Das ist keine offizielle Kennzahl aus einem Framework. Die bekannten DORA-Metriken messen etwas anderes, nämlich wie schnell eine bereits laufende Organisation Änderungen ausliefert. Für einen Projektstart ist die einfache Tagezahl bis zum ersten echten Nutzen trotzdem die aussagekräftigste Größe, die du führen kannst, und sie hat einen angenehmen Nebeneffekt: Sie ist nicht verhandelbar. Ein Team kann sich über den Reifegrad einer Pipeline streiten, über diese Zahl nicht.

Trägst du sie vom ersten Tag an mit, ändert sich die Diskussion. Aus „wir brauchen noch GitOps“ wird „was kostet GitOps an Tagen, und verschiebt es den ersten Nutzen“.

Der Durchstich zuerst: das Walking Skeleton

Die wirksamste Gegenmaßnahme ist alt und stammt aus der agilen Frühzeit. Alistair Cockburn hat den Begriff Walking Skeleton geprägt und in „Crystal Clear“ (2004) ausgearbeitet.

Gemeint ist weder ein Prototyp noch ein fertiges Modul, sondern ein Pfad. Etwas Winziges nimmt den kompletten Weg durch alle beteiligten Bausteine, und zwar bevor einer dieser Bausteine ausgebaut wird. Was dieser Pfad fachlich tut, ist zweitrangig. Wichtig ist, dass er jeden Baustein einmal anfasst, denn damit ist bewiesen, dass sie zusammenpassen.

Auf einen heutigen Cloud-Start übertragen: Es existiert ein durchgehender Weg von einem Commit bis zu einer erreichbaren URL in der Zielumgebung, bevor irgendetwas davon ausgebaut wird. Der Endpunkt darf trivial sein. Entscheidend ist, dass er echt ausgeliefert ist.

Ein solcher Durchstich ist bestanden, wenn dieser Ablauf ohne Handgriff funktioniert:

# 1. Änderung im Code, ein einziger Commit
git commit -am "add version endpoint" && git push

# 2. Pipeline läuft ohne manuellen Eingriff durch

# 3. Die Änderung ist in der Zielumgebung erreichbar
curl -s https://api.dev.example.com/version
# {"version":"2026.08.05-a1b2c3d"}

Wenn diese drei Schritte laufen, ist die riskanteste Annahme des Projekts überprüft: dass die Teile überhaupt zusammenpassen. Alles danach ist Ausbau, und Ausbau lässt sich verhandeln, verschieben und priorisieren. Ein fehlender Durchstich lässt sich nicht verhandeln, er blockiert alles.

Die zugehörige Pipeline darf am Anfang lächerlich klein sein. Genau das ist der Punkt:

name: deploy
on:
  push:
    branches: [main]

jobs:
  ship:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - run: ./mvnw -B package
      - run: docker build -t $REGISTRY/api:${{ github.sha }} .
      - run: docker push $REGISTRY/api:${{ github.sha }}
      - run: helm upgrade --install api ./chart --set image.tag=${{ github.sha }}

Kein Test-Gate, keine Signatur, keine Freigabestufe, keine Matrix über drei Stages. Das alles kommt, aber es kommt nach dem ersten Durchstich und nicht davor.

Was am ersten Tag stehen muss und was warten kann

Die schwierigste Frage in dieser Phase ist nicht, was man braucht. Man braucht am Ende fast alles. Die Frage ist, was davon vor der ersten Fachlichkeit stehen muss.

Die Spalte rechts ist die wichtigere. Sie erklärt, warum ein Thema früh stehen muss, und dieser Grund ist fast immer derselbe: Wird es später nachgezogen, muss vorhandene Substanz umgebaut werden. Alles, was sich später additiv ergänzen lässt, gehört nicht in Woche eins.

Wie dünn darf ein Fundament sein?

Es gibt einen brauchbaren Maßstab aus dem Platform Engineering. Matthew Skelton und Manuel Pais haben in „Team Topologies“ den Begriff Thinnest Viable Platform geprägt. Die Pointe steckt im Wort „thinnest“: Eine Plattform wird nicht daran gemessen, was sie alles kann, sondern daran, wie wenig sie enthalten darf, damit die Teams darauf trotzdem vorankommen. Jede Fähigkeit, die drin ist, muss anschließend von jemandem gepflegt werden, und diese Rechnung taucht in der Aufbau-Schätzung selten auf.

Für einen Projektstart lässt sich das als Frage stellen: Was ist das dünnste Fundament, auf dem die Fachlichkeit heute vorankommt? Nicht das dünnste, das man verantworten kann, und auch nicht das vollständigste, das man bauen könnte.

Der Maßstab ist deshalb so nützlich, weil er die Diskussion vom Geschmack auf einen Zweck dreht. „Brauchen wir ein Service Mesh“ ist eine Glaubensfrage. „Kommt die Fachlichkeit ohne Service Mesh heute voran“ ist beantwortbar, und die Antwort ist bei einem einzelnen Service ja.

Die drei Entscheidungen, die alles andere nach sich ziehen

Nicht alle Entscheidungen wiegen gleich. Drei bestimmen so viel Folgearbeit, dass sie bewusst und früh getroffen werden sollten. Der Rest darf sich entwickeln.

Die erste ist die Trennung der Umgebungen. Ob dev, staging und prod in getrennten Konten oder Projekten liegen oder nur durch Namespaces getrennt sind, entscheidet über Rechte, Netzwerke, Kosten-Zuordnung und darüber, wie gefährlich ein Fehlgriff ist. Das nachträglich zu ändern heißt, jede Ressource neu anzulegen.

Die zweite ist der Weg der Pipeline in die Cloud. Ob sich die Pipeline über kurzlebige Tokens ausweist oder über einen dauerhaften Schlüssel, ist keine Formalie. Der eine Weg kommt ab Tag eins ohne Geheimnis im Repository aus, der andere erzeugt einen Rotationsprozess, den jemand betreiben muss. Nicht jeder Anbieter gibt beides her, das gehört also in die Provider-Entscheidung.

Die dritte ist das Ausrollverfahren. Ob die Pipeline direkt ausrollt oder ein Agent im Cluster einen gewünschten Zustand aus Git zieht, verändert, wo die Wahrheit liegt und wie ein Rollback aussieht. Beides ist vertretbar. Teuer wird nur der Wechsel mitten im Projekt, weil er jede Stage und jedes Chart berührt.

Alles andere, von der Ingress-Wahl bis zum Migrationswerkzeug, lässt sich später mit vertretbarem Aufwand tauschen. Es lohnt sich, diese Unterscheidung im Team einmal auszusprechen, damit die Diskussionszeit dorthin fließt, wo sie etwas ändert.

Was passiert, wenn das Fundament später nachgezogen wird

Die Gegenposition zu diesem Artikel ist verbreitet und klingt vernünftig: erst die Fachlichkeit bauen, lokal, ohne Cloud, und die Infrastruktur kommt, wenn etwas zu deployen da ist. Das spart am Anfang Zeit und verschiebt die Arbeit nur.

In der Praxis kostet dieser Weg an drei Stellen. Annahmen aus der lokalen Umgebung sind bis dahin fest im Code verankert, etwa Dateipfade, Zeitzonen oder eine Datenbank, die im Test anders antwortet als die echte. Zweitens fällt der erste Deploy in die Phase, in der der Termin schon drückt, und Infrastrukturarbeit unter Termindruck ist die teuerste Variante davon. Drittens fehlt die ganze Zeit über die Rückmeldung aus einer echten Umgebung, und damit findest du genau die Fehler spät, die dort entstehen.

Wie viel Arbeit zwischen einem laufenden Deploy und echter Produktionsreife liegt, ist ein eigenes Thema. Der Weg dorthin ist in Von deployt zu produktionsreif beschrieben.

Wo Vela Atlas ansetzt

Die Liste aus dem zweiten Kapitel ist von Projekt zu Projekt bemerkenswert ähnlich. Die Fachlichkeit ist jedes Mal neu, das Fundament fast nie. Genau darauf zielt Vela Atlas: Du konfigurierst dein Projekt, Cloud, Datenbank, Stages und Services, und bekommst das Fundament fertig ausgerollt statt als Aufgabe.

Enthalten ist, was oben in der Spalte „vor der ersten Fachlogik“ steht: Spring Boot als Service-Gerüst, Terraform für die Infrastruktur, ein Kubernetes-Cluster mit Helm und ArgoCD, eine CI/CD-Pipeline, eine Datenbank mit Migrationen, dazu ein Handbuch, das die getroffenen Entscheidungen erklärt. Das ist vor allem beim Start neuer Greenfield-Projekte wertvoll, wo dieses Grundgerüst sonst von Null aufgebaut werden muss und vor der eigentlichen Entwicklung schnell Wochen kostet.

Als Cloud stehen drei Anbieter zur Wahl: Google Cloud, AWS und Scaleway. Scaleway ist die europäische Option, wenn die Daten den Kontinent nicht verlassen sollen. Was das konkret bedeutet, steht in Scaleway ist jetzt dabei.

Der Punkt ist nicht, dass niemand dieses Fundament selbst bauen könnte. Fast jedes erfahrene Team kann das. Der Punkt ist, dass diese Wochen nichts erzeugen, was das Produkt von einem anderen unterscheidet.

FAQ

Ist das nicht ein Argument gegen saubere Architektur?
Nein. Es ist ein Argument gegen Architekturarbeit ohne Rückmeldung. Ein Entwurf, der nie etwas ausgeliefert hat, ist ungeprüft, egal wie sauber er aussieht. Der Durchstich liefert die Rückmeldung, auf der sich sinnvoll weiter entwerfen lässt.

Wie schätzt man das Fundament realistisch?
Nicht als eine Position. Nimm die Liste der Einzelthemen, schätze jede Zeile getrennt und addiere. Die Summe wird deutlich größer als das Bauchgefühl, und genau diese Differenz ist der Betrag, der in Projekten regelmäßig fehlt.

Gilt das auch für Brownfield?
Nur teilweise. In einem Bestandssystem existiert das Fundament bereits, dafür sind Änderungen daran teurer. Die Falle im Bestand ist eine andere: die große Modernisierung, die parallel zum Tagesgeschäft läuft und nie fertig wird.

Lohnt sich das, wenn wir nur ein einziges Projekt haben?
Der Aufwand fällt beim ersten Projekt genauso an. Was bei mehreren Projekten dazukommt, ist die Konsistenz zwischen ihnen. Bei einem einzigen Projekt zählt vor allem, wann der erste Nutzen entsteht.

Löst eine Managed-Plattform wie Cloud Run oder App Service das Problem nicht ohnehin?
Für einen einzelnen zustandslosen Service oft ja, und dann ist das der ehrlichere Weg. Sobald mehrere Services, eine Datenbank mit Migrationen, getrennte Stages und Rechte dazukommen, ist ein großer Teil der Liste trotzdem wieder da, nur an anderer Stelle.

Was ist mit KI-Assistenten, schreiben die das Fundament nicht einfach?
Sie schreiben die einzelnen Bausteine schnell und meistens brauchbar. Was sie nicht abnehmen, ist die Entscheidung, welche Bausteine zusammenpassen müssen, und die Prüfung, ob das Ergebnis reproduzierbar ist. Der Zeitgewinn liegt beim Tippen, nicht beim Entscheiden.

Fazit

Projekte scheitern selten an schlechter Architektur. Sie scheitern daran, dass das Budget aufgebraucht ist, bevor der erste Mehrwert ausgeliefert wurde. Auf dem grünen Feld ist die Gefahr am größten, weil dort nichts bremst und alles möglich scheint.

Der nächste Schritt ist unspektakulär: Schreib auf, wie viele Tage in deinem letzten Projekt zwischen dem ersten Commit und dem ersten echten Nutzen lagen. Diese eine Zahl verändert die Reihenfolge, in der du das nächste Mal anfängst.

Quellen

• Alistair Cockburn: „Crystal Clear: A Human-Powered Methodology for Small Teams“ (2004), zum Walking Skeleton
• Team Topologies (Matthew Skelton, Manuel Pais): What is a Thinnest Viable Platform (TVP)?
• DORA: Metriken zur Auslieferungsleistung, als Abgrenzung zur hier beschriebenen Projektstart-Frage

Alle Beispiele in diesem Artikel sind eigene und bewusst auf das Nötigste gekürzt.