Methodology · Linacre Capital
A methodology for non-technical founders building complex AI systems
You’ve been lied to.
You can build software in a weekend with AI — that is the promise. The LinkedIn posts, the YouTube tutorials, the breathless threads: “I built a SaaS app in a weekend!” It looks so easy. Type a prompt, get code, ship it.
You can’t. Not anything real. The weekend-app screenshots do not show you the months that follow, when the simple build mutates into something you cannot control and the AI that was meant to be your co-pilot keeps suggesting fixes that break what was working. I know, because I tried to build something serious: Voxa, a real-time conversational AI platform, as a non-technical founder. It took more than eighty sessions, not a weekend. The Conductor Protocol is what I learned doing it.
They fail not because the AI cannot write code, but because no one is governing the build. Three patterns kill them.
The Spiral. A bug appears, the AI suggests a fix, the fix breeds a new bug, and you patch the patch. Soon the codebase is a layer of contradictory intentions and finding the original error takes forensic archaeology. I once lost eight hours to a single incorrect variable name, because the system had accumulated so many patches.
Context Amnesia. The assistants do not really remember. Every session starts from nothing unless you carry the memory for them.
Poke and Hope. Prompting blind and accepting whatever comes back. The common thread is the absence of an architect: the AI answers each prompt in isolation, and a non-technical founder does not have the knowledge to catch the contradictions.
You are not the engineer. You are also not the passenger. You are the conductor.
A conductor plays no instrument, yet sees what no single musician can: the whole. That is your role. The assistants are your musicians, organised in three tiers. The Architect (Claude Opus) handles system design, debugging method, specifications, and judgement. The Engineer (Claude Code) executes precisely, writes the actual code, and does not second-guess. QA (an independent model) gives second opinions and catches the blind spots the other two share.
And then there is you. You carry the vision, maintain the continuity the AIs cannot hold across sessions, and make the final decision — sometimes overruling the Architect, because you know things about your users and your constraints that it never will.
What separates this from vibe coding is documentation that holds the build together across sessions: a Captain’s Protocol distinguishing what is known from what is assumed; a Business Requirements Document and a Software Requirements Specification as ground truth; a Technical Wisdom Register that records every hard-won lesson so the same mistake is never made twice. The discipline is what lets a founder direct a build they could not code.
This is not theory. Four AI products have been built this way — Mindpause, Eyelink, Voxa, and Farewatch — shipping software, not slideware, built by a human, a non-coding founder. In this case, me.
The full work
The Conductor Protocol is a field manual of twenty-seven chapters across six parts — the problem, the methodology, the lessons, the economics, the proof, and implementation. This page is a synopsis; the full work is available through Linacre Capital. To read it, or to discuss directing AI builds in your own organisation, contact Bill Lewis — bill@linacre.net.
About
Bill Lewis is Founding Partner of Linacre Capital Partners. He provides independent counsel to Chairs, CEOs and Founders on their highest-stakes decisions, on the AI now operating inside their businesses, and on major programmes that are starting to tilt — bill@linacre.net.
Visit Linacre Capital.