From Vision to Production: the whole series, in one place
Over seven posts I wrote down how it actually happened: what worked, what it cost, and what failed. This is the map to all of it, so you can start wherever you want.
Consulting
Opus Max as architect: what actually changed when Fable went away
Opus Max as architect: what actually changed when Fable went away.
Short answer: less than you'd think — if you know what the tier is for.
I lost my favourite tool and shipped faster anyway
Fable was the best tool in my stack. Then it went unavailable, and I had to give the architect seat to Opus Max on short notice.What I got was faster hand-offs. This is the post about why — and why I think losing the tool made the work better, not despite the constraint but because of it.
Where the three-tier stack was overkill: an honest retrospective
Not a victory lap the opposite. Where the stack was overkill, where the hand-off cost more than it saved, and the one-question filter I now run before I stand up the architect tier at all.
The RPIQ loop: where the architect tier actually sits
That methodology is the loop I've been running long before any of these models existed: Research → Plan → Implement → Quality. RPIQ. This post maps the stack onto it — and shows why the mapping, not the model, is the thing worth keeping.
Orchestration Part3: Why I took the architect tier out of my delivery work on purpose
I pay for less AI than I could afford. On purpose. Two months ago I dropped the top tier from my subscription — the architect tier, the one with Opus Max in it. Not because it wasn't good. Because it was too good at being reached for.
Orchestration part 2: Show, don't tell: watching one request fall through the orchestration stack
Everyone wants to argue about which model is best. It's the wrong argument. The interesting question isn't "which model" — it's "what happens at the seams between them." So instead of telling you how the three-tier stack works, I'm going to show you. One real request, followed the whole way down.
