By the end of this chapter you can run a real operating system for directing multi-day builds: own the what and why, hand off the how, and verify against a bar you set, using a skill we built and give away free.
AVATAR OPENER · ~90s
Watch: running the founder-mode loop on one real, high-stakes build
HeyGen avatar · generated, consistent presenter
You now have a lot of power: councils, subagents, skills, loops, hosted agents. Power without an operating system is how people build impressive things that go nowhere. This chapter is that operating system. It is how you direct a real, multi-day build without either drowning in the details or floating away from them, and it comes as a skill we made and give away, no funnel attached.
The name comes from Paul Graham, who wrote about founder mode in 2024, describing how the best founders stay hands-on in the details that decide the outcome instead of delegating everything and disengaging. Graham was writing about a human CEO staying close to the people below their direct reports. Mapping that posture onto you directing AI is our extension, not his words, and it turns out to be exactly the discipline you need when the AI can do so much that the risk is no longer doing too little, it is losing the thread of what you were even trying to make.
Manager mode
You delegate the whole thing and step back. With AI this feels efficient and produces confident, fast work aimed at the wrong target, because you let go of the what and the why along with the how.
Result: a polished deliverable for a goal you drifted off.
VS
Founder mode
You keep the what and the why in your own hands, hand off the how, and verify what comes back against a bar you wrote down. Close where it matters, hands-off where it does not.
Result: speed you could not match, still aimed where you meant.
You own the what and the why. The execution owns the how.
This is the trade from the very first lesson, grown up. You keep the judgment, it brings the speed, held together by a loop you actually run instead of just believe in.
THE LOOP
Founder mode is not a vibe, it is a loop you run. Six moves, in order, and the whole point is that you actually do them rather than nod at them. The skill runs the loop with you; here is its shape.
Build, pivot, or kill
Before anything, decide the thing should exist at all. The most expensive work is a polished deliverable for something that should never have been built.
Lock the goal and the bar
Write four things in plain words and keep them visible: the goal, the one deliverable, what good enough means, and the checks that say it is done.
Brain-dump, get challenged
Talk it all out messy, then be challenged hard before anything is built, especially when you are excited, because that is when the setup is thinnest.
Brief, hand off, verify
Turn the locked goal into a clean brief, let the right skill build it, then judge what comes back against the bar. Trust what you can run, not what you are told.
Two of these moves are the ones people skip and regret. The premise gate, build-pivot-or-kill, gets skipped exactly when you are most excited, which is exactly when it matters most, because nothing is more expensive than beautifully executing something that should never have existed. And locking the goal in writing is what lets you catch drift later, because drift off the goal is the single most common reason good-looking output gets rejected, and you can only catch it against something you wrote down.
DECIDE, DON'T DO
The heart of founder mode is a test you can apply in the moment. If you find yourself producing the deliverable instead of judging it, stop, that is the execution's job now. And if you find yourself approving output without actually looking at it, also stop, that is your job and you are skipping it. You are the conductor, not the orchestra and not the absent patron. You decide, brief, and verify. You do not build the thing, and you do not rubber-stamp it either.
Keep the decisions
The what, the why, the bar, the go or no-go. These are yours and do not transfer. This is the judgment the whole course protects.
Hand off the doing
Producing the deliverable is the execution’s job. Brief it well, let the right skill trigger itself, and get out of its way.
Verify against the bar
Judge what comes back against the written definition of done. Trust a preview or a working demo over any summary that claims success.
The guardrail
Stay close because you understand what matters, never because you distrust the work. Founder mode is not an excuse to micromanage.
That last card is the non-negotiable, and it is Graham's own warning turned into a rule. Staying hands-on must be understanding-driven, not control-driven. On every "I will keep my hands on this," ask yourself honestly: is that because I understand what matters here, or because I do not trust the work and want control? If it is the latter, you have become the bottleneck, and founder mode has curdled into micromanagement wearing a nicer name. The discipline only works if you are ruthless about that distinction.
THE SKILL, AND IT IS YOURS
All of this is packaged as a skill called founder-mode, which we built and give away free under an open licence, no course to buy and no upsell. It runs the loop with you: the premise gate, the locked brief, the challenge, the hand-off, and the verification. It is already on our site, and like everything this course points at, it ships in the companion repo for you to copy and keep.
Here is how you invoke it on a real build. Notice you are not asking it to do the work. You are asking it to run the loop that keeps the work aimed true.
Run the founder-mode loop
Run founder mode on this with me. Do not build it yourself; be the
conductor: decide, brief, and verify.
The build: [describe the multi-day or high-stakes thing, e.g.
"launch a small paid product to my audience"].
Take me through it:
1. Premise: should this be built at all, right now? Build, pivot, or kill?
2. Lock it: goal, the one deliverable, the bar for "good enough",
and the checks that mean it is done. Keep these visible.
3. Challenge me hard before anything is built. Question the obvious.
List the access, assets, and decisions this will actually need.
4. Help me turn the locked goal into a clean brief to hand off.
5. When work comes back, hold it against the bar. Trust what I can
see and run over what I am told.
Do not narrate the machinery. Just run it with me.
Without it: you get excited, start building, and three days in you
have a polished thing aimed slightly wrong, and you cannot say
exactly what "done" was, so you keep tinkering.
With it: the premise gate makes you admit one feature should be cut
entirely. The locked bar gives you a finish line. The challenge
surfaces the one asset you did not have. You ship the right smaller
thing, on time, and you know it is done because you wrote down what
done meant.
One deeper note for the biggest builds. For multi-day work there is a heavier version of this, an operator pipeline that runs from brain-dump to spec to a phased build plan to prepared access to signed-off mockups, with a fresh-context challenger at the end. That is written up in the skill's references. You do not need it for most things. Reach for it when the build is genuinely large and the cost of drifting is high.
NOW YOU TRY · APPLY
Run founder mode on one real build
Take one real thing you want to build that is bigger than an afternoon, a product, a launch, a system. Run the founder-mode loop on it with the prompt above. Actually do the premise gate, honestly: is this worth building now? Actually write the goal, deliverable, bar, and definition of done. Let it challenge you before you build anything. The deliverable of this drill is not the thing built; it is the locked brief and an honest build-pivot-or-kill call.
Right if you have a written, locked brief for one real build and an honest premise decision, and you can tell the difference between the decisions you kept and the doing you would hand off.
Show the worked solution
The drill works when the loop changes what you were about to do, and it usually does. Say the build is "a paid membership for my audience." Excited, you would normally jump to building the site. Run the premise gate first and the honest question lands: should this exist now, or are you reaching for a membership because it sounds like a real business, when a single paid workshop would test the same demand for a tenth of the effort? Maybe that is a pivot, and catching it here saves you weeks. Say you still decide to build. Now you lock it: goal is thirty founding members in the first month; deliverable is a simple signup page plus a welcome sequence; the bar is that a stranger understands the offer and can join in under two minutes; done means the payment works end to end and a test signup receives the welcome. Then the challenge round earns its place by asking the thing you avoided: what do members actually get every month, and can you sustain it, because a membership that runs dry in month three is worse than none. That question, answered now on paper, is far cheaper than answered later in front of paying members. You walk out of the drill with a locked brief and, just as valuable, a clear-eyed decision about whether this was even the right thing to build. That is founder mode: the most useful work often happens before a single thing is made.
WATCH FOR
✗You skip the premise gate when excited. That is exactly when it matters most. Decide build, pivot, or kill before you fall in love with executing the wrong thing beautifully.
✗You start building instead of locking the goal. Write the goal, deliverable, bar, and done-checks first. Drift is the top reason output gets rejected, and you can only catch it against something written.
✗You approve output without actually looking. Rubber-stamping is not verifying. Judge against the bar, and trust what you can see and run over any summary that claims it worked.
✗You use "staying close" to justify control. Stay close because you understand what matters, never from distrust. The moment it is control-driven, you have become the bottleneck.
WHAT YOU LEARNED
The takeaways
Founder mode is the operating system for directing real builds: own the what and why, hand off the how, verify against a bar you set.
It is a loop you actually run: build-pivot-or-kill, lock the goal and bar, brain-dump then get challenged, brief and hand off, verify against done.
The test in the moment: if you are producing the deliverable, stop, that is the execution’s job; if you are approving without looking, stop, that is yours.
The guardrail is non-negotiable: stay close because you understand what matters, never because you distrust the work, or you become the bottleneck.
The founder-mode skill runs this loop with you and is ours, free and open, in the companion repo, with a heavier operator pipeline for the largest builds.
Your project · run the system
Run the founder-mode loop on one real build in your thread project, and walk out with a locked brief and an honest premise call. You now have an operating system for all the power this course gave you. Next chapter tackles the most common complaint about AI output, that it is generic slop, and gives you the passes that fix it in your own voice.
All the power in this course is only as good as your judgment about where to point it. Founder mode is that judgment made into a loop you run: decide what deserves to exist, own the why, hand off the how, and check the result against a bar you were honest enough to write down first. Keep the judgment. Give away the rest.