What failed, what it cost, and where this goes — the honest ledger

Part 6 of "From Vision to Production." Publishes Tue Jul 28, 2026.

Every post in this series so far has shown you something that worked — the phases, the team, the method, the quality system. This one is the ledger. The failures, the real numbers, and an honest answer to the question I get most: should you actually do this?

Let me start with the number, because it's the one people don't believe.

The economics

The entire AI stack that built and now maintains a production app — the tooling, the compute, the models — costs me roughly €240 a month. The alternative, the conventional way to get the same output, is a development team whose equivalent salary sits somewhere around €120,000 to €180,000 a year.

I want to be careful here, because the gap is so large it invites a lazy conclusion. This does not mean a subscription replaces a team. It means that a single domain expert, with a method and a lot of discipline, can now produce something that used to require a team's budget. That's a different and more interesting claim. The cost of trying has collapsed. What hasn't collapsed is the cost of doing it well — that's paid in judgment, not euros.

Three failures that taught me most

I didn't arrive at the method in this series by being clever. I arrived at it by breaking things, expensively, three times over.

Over-engineering. Given a capable model and no friction, I built for scale that never came — abstractions, configuration, flexibility for futures that didn't arrive. AI makes it cheap to over-build, which means it makes it easy. The fix was ruthless scope gates: every piece of work had to justify its own existence before it was allowed in.

Context drift. The model would lose the thread mid-build and I'd ship the confusion. That's what pushed me to the templates and the RPIQ loop from Part 4 — pinning context every time instead of hoping it survived the conversation.

Confirmation bias. The most expensive of the three, because it was invisible. The model that wrote the code reviewed the code and approved it, carrying the same blind spots into both jobs. It took the cross-model review gates from Part 5 to break the echo.

Each failure cost me real time. Each one also became a piece of the system — which is the only reason I'm willing to talk about them in public.

What actually shifted

The question underneath all of this isn't "can AI write code." It obviously can. The question is what changes for a person like me — twenty years in QA, zero Swift — when it can.

What shifted wasn't that I stopped needing skill. It's that the skill moved. Less writing every line, more directing and reviewing. Less syntax mastery, more context engineering. Less doing the work myself, more designing the gates that decide whether the work is good. Less individual output, more orchestrating a team I can't see. The domain expertise I already had became the scarce, valuable input. The implementation became the part I could delegate.

That's the real story for solo founders and domain experts: the bottleneck moved from can you build it to do you know what's worth building and how to tell if it's right.

See the whole thing live at CAST26

This is where the series has been heading. Everything I've written across these six weeks — the phases, the agent team, RPIQ, the quality gates, these economics — I put on stage, end to end, with the real codebase behind it.

If any of this has been useful, come see the full version. CAST 2026 (CAST26), August 3–5, 2026, in Cocoa Beach, FL. Tutorials on the 3rd, conference on the 4th and 5th. Come find me, and come with hard questions — those are the ones worth answering.

Thanks for reading the arc.

See you in Cocoa Beach.