In Duncan Rogoff's video, the viral REA repository is the hook, not the whole story. REA helps coding agents investigate software without its original source. Duncan uses that to ask a harder question for anyone selling an app: if a competitor can reproduce the visible feature set, why would a customer continue paying you? His answer is a useful business lens, even though “AI can copy any app” is an overstatement of what the tool or the examples prove.
REA reduces some of the work of understanding software, but it does not automatically recreate a complete, lawful, production-ready product. Duncan argues that customers keep paying for three harder-to-copy things: a result they care about, someone accountable when delivery fails, and a trusted path to the product. Those advantages still need to be demonstrated with customers, not declared as a “moat” in a pitch deck.
Watch Duncan Rogoff's Argument
Credit: The examples and three-part business argument are Duncan Rogoff's. The technical and responsible-use details below are checked against REA's official repository and its disclaimer. Duncan promotes his Claude Code Club in the video; this article is not affiliated with it.
What REA Changes, and What It Does Not
REA is an MCP server and CLI that lets an agent use analysis workflows across supported targets. For native binaries, it can work with separately obtained tools such as Ghidra, Hopper, or IDA; its JavaScript, Electron, and .NET workflows have different prerequisites. Results can include pseudocode, assembly, modules, call relationships, and evidence for a hypothesis. The agent can then write and test a new implementation. This is not recovery of the developer's original project or permission to reuse its code or assets.
Duncan says the repository jumped from roughly 13,000 to 149,000 stars in five days. That is a snapshot from his recording, not a stable usage metric: the live GitHub page already displays a different count. Stars, downloads, and a dramatic demo tell us there is attention; they do not measure successful installations, safe use, or commercial adoption. The official setup path is documented in the README; it requires a supported Node.js runtime, changes agent configuration with review, and may need a separate native analysis engine. Read the proposed changes before installing anything.
Three Examples, Three Standards of Proof
PowerToys Color Picker
What Duncan reports
A developer inspected the finished Windows utility without giving the agent its source, checked nine findings against Microsoft's public implementation, and built a smaller color picker. Duncan reports eight findings fully correct.
What it establishes
The public PowerToys source makes this a potentially checkable example, but this article could not independently locate the developer's full experiment or reproduce its scoring. Treat the eight-of-nine figure as Duncan's report, not our benchmark.
DX-Ball sound panning
What the project documents
The REA case study traces a specific position-to-audio-pan calculation from the old executable. Its reconstructed function passes 3,205 original-x86 cases and matches 63 compiled function bytes.
What it does not establish
This is unusually strong evidence for one function. It is not proof that the entire game was reproduced byte for byte or that other applications will be as tractable.
Accounting-app story
What Duncan reports
He describes a developer who examined a QuickBooks trial and later built an open-source accounting tool with invoices, bank imports, and reports. Duncan also says this took substantial work rather than one automatic clone step.
What remains open
No project or test link is supplied with this example, so its implementation, compatibility, and permissions are not independently verified here. Do not treat it as a recommendation to analyze a commercial trial or to move real books into an untested substitute.
Duncan also points to ArtCraft, which approaches similar creative tools from observable behavior and public material rather than opening Adobe binaries. Our seven-app review covers the feature and file-format checks that matter before anyone switches. A familiar interface and a feature list are still different from reliable professional parity.
Who Should Use REA?
There are legitimate reasons to inspect software: security research, understanding a system you own, interoperability, preservation, and authorized migration. The project's responsible-use document expressly rejects copying protected code and assets, bypassing DRM or licenses, and using the tool without appropriate rights. Having a trial installer or a public download does not by itself authorize every form of analysis. Applicable contracts and law vary; get advice before a commercial project with uncertain rights.
There is also a practical boundary. Native investigation may require another installed analysis engine and technical judgment about evidence. Runtime inspection can execute a target with the current user's permissions, and local analysis results may still go to the agent's model provider. Start with software you own or have explicit permission to examine, use an isolated sample, review setup and data flows, and verify the inferred behavior independently. If your aim is merely to ship your first useful product, REA is probably not the first tool you need.
The Three Reasons Customers May Stay
1. A result, not a feature list
Duncan's point
A post-writing tool is easy to compare on buttons and price. A service that reliably helps a client book qualified calls is judged on the outcome and the work behind it.
How to test it
Choose a buyer-owned metric, establish a baseline, and agree on what counts. A claimed outcome without attribution, quality control, or a realistic delivery cost is not a durable advantage.
2. Someone accountable when it breaks
Duncan's point
Free or cheaper code can become costly when payroll, books, or a critical workflow fails. Buyers pay for support, backups, and a person or team that will take responsibility.
How to test it
Write a response promise you can meet, define escalation and recovery, and measure actual resolution time. A support claim is only valuable if it works during the bad week.
3. Trust and distribution
Duncan's point
He points to his own paid teaching community: people can find free Claude content, yet some pay for his sequence, guidance, and relationship. The member and price figures in the video are his own report.
How to test it
Look for repeat referrals, qualified inbound enquiries, renewals, and willingness to pay. Audience size alone is not trust, and trust alone will not repair a weak product.
A One-Week Test for Your Own Product
Use Duncan's question: If a lawful competitor matched the visible features tomorrow, what would make customers stay? Write one sentence, then check it with five customers or credible prospects. Ask for a recent outcome, a support incident, and how they first learned to trust you. Pick the weakest of the three areas and make one observable improvement this week: a before-and-after report, a tested recovery runbook, or a case study with clear limits. If nobody values the improvement, change the offer instead of polishing the slogan.
Jump to Duncan's Video
| Time | Segment | Time | Segment |
|---|---|---|---|
| 00:00 | Why REA spread | 02:40 | What REA is |
| 04:37 | Examples and capabilities | 06:39 | Who should use it |
| 08:15 | Where is the moat? | 10:18 | Pay for a result |
| 11:07 | Pay for support | 11:45 | Pay for trust |
| 12:25 | The bigger picture |
Business Idea: Sell the Outcome Around a Simple Tool
The copyable prompt below turns Duncan's three-part argument into a testable offer. It does not require REA or competitor inspection; it asks what a buyer will still value if the interface becomes easy to reproduce.
Stress-test your moat
Design one measurable offer with real support and a way to earn trust.
Sources and Limits
Primary video: Duncan Rogoff's full argument. Project documentation: REA README, responsible-use guidance, DX-Ball case study, and reconstruction repository. Comparison context: ArtCraft app directory. The color-picker and accounting-app stories, club figures, and viral-growth figures are presented as Duncan's claims, not independently reproduced tests. This is a strategic and technical summary, not legal advice or a claim that every app can be copied.