Vom Architekten zum Builder — Was IBM-Großprojekte einem Solo-Founder beibringen

TL;DR

Nach 15 Jahren System-Software-Architektur bei PwC und IBM (Großprojekt Vista in Zürich, internationale Banking-Systeme zwischen 1999 und 2014) wechselte ich 2015 in die Selbstständigkeit, 2024 in den Indie-Builder-Modus. Dieser Post zerlegt: fünf Pattern aus der Großprojekt-Welt, die ich unverändert weiternutze (Trennung von Spec und Implementation, Reversibility-Bias, Kontext-Disziplin, kalkuliertes Wegwerfen, Anti-NIH), und drei, die aktiv schaden (Stakeholder-Management-Reflex, Process-as-Risk-Mitigation, Roadmap-Disziplin in Quartal-Schritten). Das ist keine “man muss zuerst Junior werden”-Geschichte — der größte Hebel war zu unterscheiden, was übersetzbar ist und was Ballast.

Featured-Image-Platzhalter: stilisierter Karriere-Bogen mit IBM-Phase und Indie-Phase. Asset folgt.

Inhaltsverzeichnis

• Der Kontext: 15 Jahre Großprojekt-Architektur
• Fünf Pattern, die direkt übersetzbar sind
• Drei Pattern, die aktiv schaden
• Was nicht aus IBM kam, sondern aus dem Wechsel selbst
• Wann der Wechsel sinnvoll ist (und wann nicht)
• FAQ

Der Kontext: 15 Jahre Großprojekt-Architektur

Damit die Behauptungen einsortierbar sind:

15 Jahre PwC/IBM, davon 5 in einem einzigen Zürcher Banking-Projekt mit ~80 Beteiligten quer durch 4 Zeitzonen. Das ist Großprojekt-Realität — nicht Theorie aus einem Architecture-Buch.

Fünf Pattern, die direkt übersetzbar sind

Diese fünf nutze ich heute genauso wie damals — nur skalieren sie für eine Person statt 80.

1. Trennung von Spezifikation und Implementation

Im Vista-Projekt war das organisatorisch trivial: Architekten schrieben Specs, Entwickler implementierten. Heute mache ich beides — aber zeitlich getrennt. Vormittags entwerfe ich (PRD, API-Design, DB-Schema). Nachmittags implementiere ich. Cross-over kostet Qualität.

Das passt auch zu Anthropics Empfehlung zu Spec-Driven Development mit Claude Code: erst den Plan in einer Datei, dann den Plan ausführen lassen. Was wir 2010 mit Word-Specs gemacht haben, ist heute markdown-PRDs für Agenten. Gleiches Muster, kleinere Skala.

2. Reversibility-Bias

Im Großprojekt ist Vista-Lektion #1 gewesen: nicht-reversible Entscheidungen sind 10× teurer als reversible. Eine Schema-Migration ist reversibel (mit Aufwand). Eine Cross-Cutting-Architecture-Entscheidung wie “wir wechseln zu Microservices” ist nicht.

Im Indie-Builder-Modus heißt das: ein neues Repo ist reversibel (löschen kostet nichts), ein gewählter Tech-Stack ist nicht. Ich überlege Stack-Entscheidungen 10× sorgfältiger als Feature-Entscheidungen. Bonblick als Flutter-Projekt war eine reversibility-bewusste Entscheidung. Conductor in Go war es auch.

3. Kontext-Disziplin

In einem 80-Mann-Großprojekt muss jeder Beteiligte schnell auf Stand kommen — wer wo angefangen hat, was offen ist, wer wartet. Wir hatten Wiki-Konventionen, Confluence-Diskussionen, weekly status updates.

Heute mache ich das gleiche, aber für eine Person und einen Claude. CLAUDE.md in jedem Repo. knowhow project-status als Plugin in Conductor. Der Trick ist nicht das Tool — der Trick ist die Disziplin, jeden Wiedereinstieg zu dokumentieren, bevor man weiterarbeitet. Großprojekt-Architekten lernen das in den ersten 12 Monaten. Solo Founder ohne den Hintergrund müssen es sich erarbeiten.

4. Kalkuliertes Wegwerfen

In Vista haben wir mindestens 3 komplette Implementations-Stränge weggeworfen, weil die Annahmen sich als falsch erwiesen. Das war strukturell akzeptiert — Sunk-Cost gehört zur Architekturarbeit.

Im Indie-Modus ist das die Grundlage der 424-Repo-Methode. Ein Repo nach 7 Tagen archivieren weil die Idee tot ist, ist Großprojekt-Disziplin im Mikro-Maßstab. Wer 15 Jahre lang 6-Monats-Implementations-Stränge wegwerfen musste, hat keinen emotionalen Widerstand mehr beim 6-Tage-Stränge-Wegwerfen.

5. Anti-NIH (Not Invented Here)

Im Großprojekt war “wir kaufen statt selbst zu bauen” eine reflexive Default-Entscheidung. Spring statt Custom-Framework, Oracle statt Custom-DB, Tibco statt Custom-Messaging. Diese Disziplin überträgt sich 1:1. Astro statt eigener Static-Site-Generator. Cloudflare Pages statt eigene Build-Pipeline. Claude Code statt eigener AI-Agent. Postgres + Drift statt eigener ORM.

Solo Founder ohne diese Disziplin bauen oft 3× zu viel selbst. Großprojekt-Erfahrung schützt davor automatisch.

Inline-Image-Platzhalter: Mapping-Diagramm der 5 Pattern. Asset folgt.

Drei Pattern, die aktiv schaden

Diese drei waren in der Großprojekt-Welt notwendig — im Indie-Modus sind sie Gift.

1. Stakeholder-Management-Reflex

In Vista hatte ich zu jedem Zeitpunkt mindestens 6 Stakeholder zu managen — Banken-CIO, Compliance, Audit, PMO, Architecture Board, Test-Team. Jede Entscheidung musste durch mindestens 3 dieser Filter.

Indie Founder zu sein heißt: 0 Stakeholder außer der Markt. Der Reflex, Entscheidungen vor jemandem rechtfertigen zu müssen, ist Karriere-Ballast. Ich habe ihn die ersten 2 Jahre Selbstständigkeit nicht abgelegt — und damit Entscheidungs-Latenz produziert, die niemand bezahlte.

Fix: wenn ich mich dabei ertappe, eine Entscheidung “vorzubereiten für ein imaginäres Audit”, abbrechen und einfach entscheiden. Reality-Check kommt vom Markt, nicht vom Audit Board.

2. Process-as-Risk-Mitigation

Großprojekt-Process ist Risiko-Mitigation für Fehler, die Millionen kosten. Code Review, Architecture Review, Change Advisory Board, Test Gates — alle haben einen Sinn, wenn Fehler im Live-System nicht zurückgenommen werden können.

Indie-Builder-Fehler sind in 99% der Fälle reversibel. Process-Overhead frisst Zeit, die das Geschäft nicht bezahlen kann. Ich habe mein erstes Solo-Jahr (2015) damit verbracht, mir leichte CI/CD-Pipelines und PR-Reviews aufzubürden — als wäre ich Audit-pflichtig. Niemand hat es gebraucht.

Fix: Process erst einführen, wenn der Schmerz konkret ist. Nicht prophylaktisch.

3. Roadmap-Disziplin in Quartal-Schritten

In Vista waren Quartals-Reviews unausweichlich. Die ganze Architektur war auf 12-Monats-Releases ausgelegt. Roadmaps wurden auf 18 Monate geplant, monatlich aktualisiert.

Im Indie-Modus ist die Quartal-Roadmap tot. Per meiner Beobachtung zur DNA-Kalibrierung: was früher ein Quartal-Projekt war, ist heute eine Mittagspause. Wer 12-Monats-Roadmaps für Indie-Projekte plant, plant gegen die eigene Geschwindigkeit. Realistische Indie-Roadmap-Horizonte: 4 Wochen maximum, oft 2.

Fix: Pläne sind nicht-bindend. Die Methode ist eine Idee, ein Repo, Reality-Check vor Diskussion.

Was nicht aus IBM kam, sondern aus dem Wechsel selbst

Drei Dinge, die ich erst nach dem Wechsel gelernt habe — nicht trotz, sondern wegen des Architekten-Hintergrunds:

1. Latenz-Minimierung. Im Großprojekt war es egal, ob eine Entscheidung 3 Tage oder 3 Wochen brauchte. Im Indie-Modus ist das der Unterschied zwischen Markt-Timing und Verpassen. Architekten müssen lernen, in Tagen statt Wochen zu denken.
2. First-Person-Marketing. In IBM hat das Marketing-Team Texte geschrieben. Indie heißt: du bist der Marketing-Text. Diese Site ist mein Reality-Check, ob ich es kann (Conductor sagt: ja, mit Hilfe).
3. Direkter Kunden-Kontakt. Vista-Architekten redeten mit Bank-CIOs, nicht mit Endnutzern. Indie heißt: jeder erste Anruf ist Endnutzer-Anruf. Das ist eine andere Skill als Architektur.

Diese drei sind die einzigen Bereiche, in denen IBM mir aktiv im Weg stand. Alles andere war Vorteil.

Inline-Image-Platzhalter: 2-Spalten-Vergleich übersetzbare vs ablegen-Skills. Asset folgt.

Wann der Wechsel sinnvoll ist (und wann nicht)

Drei Bedingungen pro Seite.

Wechsel ist sinnvoll, wenn alle drei zutreffen:

1. Du langweilst dich strukturell. Nicht “der aktuelle Sprint nervt”, sondern: das ganze Spielfeld ist erschöpft. Bei mir 2023 war das der Fall.
2. Du hast ≥12 Monate finanzielle Reserve. Indie-Pre-Revenue-Phase ist normal 12-18 Monate. Ohne Reserve = Stress = schlechte Entscheidungen.
3. Du hast Lust am Bauen, nicht am Beraten. Wer als Architekt vor allem aus Power und Sichtbarkeit lebt, wird im Indie-Mode unglücklich. Indie heißt: kein Power-Layer, nur Code + Kunde + Markt.

Wechsel ist nicht sinnvoll, wenn:

1. Du als Architekt nur das Geld vermisst. Geld ist im Indie-Modus instabiler, nicht besser.
2. Du Process-Liebhaber bist. Indie ist Anti-Process. Wenn ITIL und ISO 9001 für dich Religion sind, bleib in Konzernen.
3. Du ein 12-Monats-Big-Bang-Release-Mensch bist. Indie ist Wochen-Iteration. Die Frequenz ist anders.

Wo das hingeht

Aus 30 Jahren Software ist mein nächster Schritt nicht “noch mehr Indie-Projekte” — es ist die Frage, wie ich die Architektur-Disziplin systematisch in Indie-Tools überführe. Conductor v9 ist der nächste Schritt. Spec-Driven Development, deterministische Orchestrierung, kalkuliertes Wegwerfen — Vista-Pattern auf Indie-Skala kondensiert.

Wenn du selbst diesen Wechsel überlegst oder gerade vollzogen hast: schreib mir auf LinkedIn.

FAQ

Muss ich erst Architekt werden, bevor ich Indie Builder werden kann?

Nein. Aber Architekten-Erfahrung verkürzt die Lernkurve in den fünf übersetzbaren Pattern oben um Jahre. Wer ohne Architektur-Hintergrund startet, muss Reversibility-Bias, Kontext-Disziplin und kalkuliertes Wegwerfen am laufenden Geschäft lernen. Möglich, teurer.

Wie lange dauert die Umstellung vom Architekt zum Indie Builder?

In meinem Fall waren es 9 Jahre vom ersten Selbstständigkeits-Schritt (2015) zum echten Indie-Builder-Modus (2024). Davon waren 8 Jahre noch “Freelance-Architektur in größeren Kontexten” — die echte Indie-Bauphase ist neu. Wer schneller will: ~12-18 Monate für die mentale Umstellung allein.

Was ist der teuerste Architektur-Reflex im Indie-Modus?

Stakeholder-Imagination. Ich habe Jahre damit verbracht, Entscheidungen für niemanden zu rechtfertigen. Diese mentale Last fällt nicht von alleine weg — sie muss bewusst abgelegt werden.

Wann ist man “Indie Builder” und wann nur “Freelancer”?

Freelancer verkauft Zeit gegen Geld für Kunden-Projekte. Indie Builder baut eigene Produkte und macht den Reality-Check am Markt. Beide sind legitim, aber das ist nicht das Gleiche. Ich war 9 Jahre Freelancer (2015-2023), bin seit 2024 Indie Builder. Der Unterschied ist nicht das Tooling, sondern das Was wird gebaut.

Soll ich meinen Architekten-Job kündigen, um Indie Builder zu werden?

Erst Reserve aufbauen (≥12 Monate), dann Side-Projekt-Phase (~6-12 Monate parallel), dann Wechsel. Ein direkter Sprung ohne Reserve führt zu schlechten Entscheidungen — und schlechte Entscheidungen sind im Indie-Modus teurer als im Architektenjob.

Geschrieben am 17. Mai 2026 in Hamburg. Wenn du diesen Post hilfreich findest, verlinke ihn — die Architekt-zu-Builder-Übersetzung ist im Diskurs unterrepräsentiert.