I rarely watch a two-hour video to the end. I watched this one with the laptop shut and a notebook next to me, because something happened halfway through that I wanted to copy immediately. On 10 August, Nate Herk took an AI product from nothing to a working paid app inside one working day and filmed the whole run. The interesting part was not the app. It was how he checked himself.
His trick: he ran two different coding agents against each other. Claude Code built, and Codex was told to break the result. Not “see whether it works”, but “click every button, upload junk, hunt for holes, and tell me what has to be fixed before a customer walks in”. That is a prompt you can copy today, whatever you are building.
What the day looked like
| Phase | What ran | Outcome |
|---|---|---|
| Research | Five research agents in parallel across YouTube, a Skool community, X and Reddit | Three product ideas, with pricing signals |
| Planning | Claude on Fable 5 as project manager, never as executor | One plan document every agent reads from |
| Building | Sub-agents on Opus and Sonnet, one work stream each | A Next.js app with Supabase and Stripe |
| Breaking | Codex driving the running app with computer use | Two launch blockers and a stack of bugs |
| Fixing | Codex repairs what Codex found, Claude keeps building elsewhere | 85 verification checks |
The division of labour is the part to steal. The planning model executes nothing, because burning expensive tokens on work a cheaper model handles fine is a waste. It only delegates. He reports spending 3 percent of his weekly Fable allowance on a day that had nine agents building at once.
The research most people skip
Ideation cost him an hour of waiting. He pointed agents at his own channels: roughly 16,000 YouTube comments, 8,000 posts inside his community, 4,000 posts on X and about 20,000 Reddit comments. That adds up to around 48,000, while the video description claims more than 60,000. The on-screen numbers are the more conservative claim, so those are the ones I use.
Two things there matter more to me than the number itself.
First, the research inverted his own assumption. He had been thinking 5 to 25 dollars a month. The agents came back with 835 sentences about price pulled from Reddit threads and a consistent band around them: 25 to 50 dollars a month, and you need one to two hundred of those customers. That correction is the entire reason to dig through the pile.
Second, he said out loud that the idea he picked has no defensible position. Someone can use it for a month, work out how it functions and rebuild it. His conclusion: the value sits in the prompt behind the button, in the expertise and the mistakes you baked into it. Anyone who starts this research without a field of their own gets the same generic answer as everyone else asking the same question.
Where it went wrong
This is the part a demo usually leaves out. When the app moved to its own domain, login broke. The security layer rejected the form because the configured site URL still pointed at the old address. The app worked on the temporary address and failed on the real one, which is the nastiest version of the problem: everything looks finished and the first visitor hits a wall.
Codex did not catch that one in advance. It did catch two blockers that would otherwise have shipped, including a deck that presented a client with a zero-times return on investment. An approval step that was never enforced was the other. Those are not cosmetic flaws, they are the kind of thing that damages your business the moment someone pays.
Costs on the other side came out low. A full customer journey, from analysis to generated document, ran to about 13 US cents. The subscription price in his test sat at 39 dollars a month.
The caveat
The bar moves to “looks finished”. Eight hours for something with login, payments and its own domain drops the cost of launching close to zero. The cost of maintaining it has not moved an inch. Herk says as much himself: you do not build a product in a day and then never touch it again. What now looks easier than it is, is not the building but the year after it.
Responsibility lands on whoever wrote the prompt. Two agents checking each other feels like oversight, but they are two systems of the same kind, carrying the same blind spots. Neither of them found the domain problem. If your name is on the checkout page, you are the verification, not them.
Understanding drains away that you will need later. Anyone who has built an authentication layer recognises that rejection within a minute. Anyone who had it built has to ask the model. That works until the model is wrong, and then you are stuck on something that is nominally yours. Herk puts it well: you can outsource the thinking and the collecting, never the understanding.
One more thing about the source. The video carries paid links, among them the dictation tool he speaks everything into and a hosting company with his own discount code. That does not make the method less useful, but the tool choices were not made in a vacuum.
What I do myself
I am not going to build a product in a day. What I am adopting is the breaking round as a fixed step. I already work with verification where the agent has to run its own work, and this is the obvious next layer: a second model that watched none of the building and gets one instruction, which is to break it. It is the same reason an afternoon of real work with Fable 5 left me slightly uneasy: the agent caught its own failures before I saw them, which is pleasant and is not outside scrutiny.
Two things I am leaving behind. The 30-day sales plan from the second hour is aimed at people running an agency, which I am not. And I will not outsource research to agents without data of my own, for exactly the reason he names.
Frequently asked questions
Do I need two paid subscriptions to try this?
Not for the core of it. The breaking round works inside a single tool as long as you start a fresh session with none of the build history. The effect is weaker, because the same model carries the same assumptions along, but it still catches plenty. Two different models work better and cost more.
Does this apply if I am not building an app?
Yes, and that is what I use it for. Any output an agent hands you can go to a second session with instructions to tear it down. For writing I ask for the weakest claim and the missing source, for scripts I ask for the input that crashes it.
How is this different from asking for tests?
Tests check what you thought of. A breaking round with computer use clicks through the real interface and finds what nobody thought of, such as a button that stays active while every field is empty. You want both, because they catch different things.
Sources
- Nate Herk, “Build & Sell AI SaaS Products (2 HOUR COURSE)”, YouTube, 10 August 2026. A 2 hour 22 minute video, plus the description with its chapter list.
- Auto-generated captions for the same video, retrieved 11 August 2026.
Checked on 11 August 2026. Every figure here comes from the video itself and none of it is independently verifiable: I have no access to his dashboards, his invoice or his database. Two things contradict each other. The description claims more than 60,000 comments searched, while the counts he states on screen add up to roughly 48,000, and I use the lower number. He also refers to his security review as “OWASP 5.0” alongside a GitHub repository that is not legible on screen, so which standard was actually applied is something I could not establish.