From Architect to Builder — What IBM Megaprojects Teach a Solo Founder

TL;DR

After 15 years of system software architecture at PwC and IBM (the Zurich Vista megaproject, international banking systems between 1999 and 2014), I went into independent work in 2015 and into indie-builder mode in 2024. This post breaks down: five patterns from the megaproject world that I still use unchanged (spec/implementation separation, reversibility bias, context discipline, calculated throwaway, anti-NIH), and three that actively hurt (stakeholder management reflex, process-as-risk-mitigation, quarterly roadmap discipline). This is not a “you must be a junior first” story — the biggest lever was learning what is translatable and what is dead weight.

Featured image placeholder: stylized career arc with IBM phase and indie phase. Asset pending.

Table of Contents

• The context: 15 years of megaproject architecture
• Five patterns that translate directly
• Three patterns that actively hurt
• What did not come from IBM but from the switch itself
• When the switch makes sense (and when it does not)
• FAQ

The context: 15 years of megaproject architecture

So the claims here are anchored:

15 years at PwC/IBM, 5 of them in a single Zurich banking megaproject with ~80 participants across 4 time zones. That is real megaproject reality — not theory from an architecture book.

Five patterns that translate directly

These five I still use today exactly as I did then — only scaled for one person instead of 80.

1. Separation of specification and implementation

In Vista, this was organizationally trivial: architects wrote specs, developers implemented. Today I do both — but at different times of day. Mornings I design (PRD, API design, DB schema). Afternoons I implement. Cross-over costs quality.

This also matches Anthropic’s spec-driven development recommendation with Claude Code: plan in a file first, then have the plan executed. What we did in 2010 with Word specs is today markdown PRDs for agents. Same pattern, smaller scale.

2. Reversibility bias

In a megaproject Vista lesson #1 was: non-reversible decisions are 10× more expensive than reversible ones. A schema migration is reversible (with effort). A cross-cutting architecture decision like “we switch to microservices” is not.

In indie-builder mode that means: a new repo is reversible (deleting costs nothing), a chosen tech stack is not. I weigh stack decisions 10× more carefully than feature decisions. Bonblick as a Flutter project was a reversibility-aware decision. Conductor in Go was as well.

3. Context discipline

In an 80-person megaproject everyone has to get up to speed fast — who started where, what is open, who is waiting. We had wiki conventions, Confluence discussions, weekly status updates.

Today I do the same thing, but for one person and one Claude. CLAUDE.md in every repo. knowhow project-status as a plugin in Conductor. The trick is not the tool — the trick is the discipline to document every re-entry before continuing work. Megaproject architects learn this in the first 12 months. Solo founders without that background have to earn it.

4. Calculated throwaway

In Vista we threw away at least 3 full implementation tracks because assumptions turned out wrong. That was structurally accepted — sunk cost is part of architecture work.

In indie mode this is the foundation of the 424-repo method. Archiving a repo after 7 days because the idea is dead is megaproject discipline at micro-scale. Anyone who had to throw away 6-month implementation tracks for 15 years has no emotional resistance to throwing away 6-day tracks.

5. Anti-NIH (Not Invented Here)

In the megaproject world “buy not build” was a default reflex. Spring instead of custom framework, Oracle instead of custom DB, Tibco instead of custom messaging. This discipline transfers 1:1. Astro instead of a custom static site generator. Cloudflare Pages instead of a custom build pipeline. Claude Code instead of a custom AI agent. Postgres + Drift instead of a custom ORM.

Solo founders without this discipline often build 3× too much themselves. Megaproject experience protects against that automatically.

Inline image placeholder: mapping diagram of the 5 patterns. Asset pending.

Three patterns that actively hurt

These three were necessary in the megaproject world — in indie mode they are poison.

1. Stakeholder management reflex

In Vista I had at any given time at least 6 stakeholders to manage — bank CIO, compliance, audit, PMO, architecture board, test team. Every decision had to pass through at least 3 of these filters.

Being an indie founder means: 0 stakeholders except the market. The reflex of having to justify decisions to someone is career baggage. I did not shed it in my first 2 freelance years — and produced decision latency no one paid for.

Fix: when I catch myself “preparing a decision for an imaginary audit,” abort and just decide. Reality-check comes from the market, not from an audit board.

2. Process as risk mitigation

Megaproject process is risk mitigation for failures that cost millions. Code review, architecture review, change advisory board, test gates — all make sense when live-system failures cannot be rolled back.

99% of indie-builder failures are reversible. Process overhead eats time the business cannot pay for. I spent my first solo year (2015) burdening myself with light CI/CD pipelines and PR reviews — as if I were audit-bound. No one needed it.

Fix: add process only when the pain is concrete. Not prophylactically.

3. Quarterly roadmap discipline

In Vista quarterly reviews were unavoidable. The entire architecture was laid out for 12-month releases. Roadmaps were planned across 18 months, updated monthly.

In indie mode the quarterly roadmap is dead. Per my DNA calibration observation: what used to be a quarterly project is now a lunch break. Anyone who plans 12-month roadmaps for indie projects plans against their own velocity. Realistic indie roadmap horizons: 4 weeks maximum, often 2.

Fix: plans are non-binding. The method is one idea, one repo, reality-check before discussion.

What did not come from IBM but from the switch itself

Three things I only learned after the switch — not despite, but because of the architect background:

1. Latency minimization. In the megaproject world it did not matter if a decision took 3 days or 3 weeks. In indie mode this is the difference between market timing and missing. Architects have to learn to think in days, not weeks.
2. First-person marketing. At IBM the marketing team wrote text. Indie means: you are the marketing text. This site is my reality check on whether I can do it (Conductor says: yes, with help).
3. Direct customer contact. Vista architects talked to bank CIOs, not end users. Indie means: every first call is an end-user call. That is a different skill from architecture.

Those three are the only areas where IBM actively stood in my way. Everything else was an advantage.

Inline image placeholder: 2-column comparison translatable vs drop. Asset pending.

When the switch makes sense (and when it does not)

Three conditions per side.

The switch makes sense if all three apply:

1. You are structurally bored. Not “the current sprint is annoying,” but: the whole playing field is exhausted. For me in 2023, that was the case.
2. You have ≥12 months financial runway. Indie pre-revenue phase is normally 12-18 months. Without runway = stress = bad decisions.
3. You enjoy building, not consulting. Anyone who as an architect lived mainly off power and visibility will be unhappy in indie mode. Indie means: no power layer, just code + customer + market.

The switch does not make sense if:

1. As an architect you only miss the money. Money is more unstable in indie mode, not better.
2. You love process. Indie is anti-process. If ITIL and ISO 9001 are religion for you, stay in big companies.
3. You are a 12-month-big-bang-release person. Indie is week-iteration. The frequency is different.

Where this goes next

After 30 years in software, my next step is not “more indie projects” — it is figuring out how to translate architecture discipline systematically into indie tools. Conductor v9 is the next step. Spec-driven development, deterministic orchestration, calculated throwaway — Vista patterns condensed to indie scale.

If you are considering this switch or just made it: reach me on LinkedIn.

FAQ

Do I have to become an architect first to become an indie builder?

No. But architecture experience shortens the learning curve on the five translatable patterns above by years. Anyone starting without an architecture background has to learn reversibility bias, context discipline, and calculated throwaway on the running business. Possible, more expensive.

How long does the switch from architect to indie builder take?

In my case it was 9 years from the first freelance step (2015) to true indie-builder mode (2024). 8 of those years were still “freelance architecture in larger contexts” — the real indie build phase is new. Faster route: ~12-18 months for the mental switch alone.

What is the most expensive architect reflex in indie mode?

Stakeholder imagination. I spent years justifying decisions to no one. That mental load does not fall off by itself — it has to be deliberately discarded.

When is someone an “indie builder” vs just a “freelancer”?

A freelancer sells time for money on client projects. An indie builder builds their own products and reality-checks them in the market. Both are legitimate, but they are not the same thing. I was a freelancer for 9 years (2015-2023), have been an indie builder since 2024. The difference is not the tooling but what gets built.

Should I quit my architect job to become an indie builder?

First build runway (≥12 months), then a side-project phase (~6-12 months in parallel), then switch. A direct jump without runway leads to bad decisions — and bad decisions are more expensive in indie mode than in the architect job.

Written on May 17, 2026 in Hamburg. If you find this post useful, link to it — the architect-to-builder translation is underrepresented in the discourse.