REA Case Studies: How Devs Reverse-Engineered QuickBooks and Notion
How developers used the REA tool to study QuickBooks Desktop and Notion's clipboard system, then built independent apps from what they learned.
What is REA and what does it actually do?
REA, short for Reverse Engineer Anything, is a tool that plugs into coding agents like Claude Code or Codex and lets them open up existing software on your computer to show you how it works internally. Instead of guessing at a feature from a screenshot or a changelog, you point the agent at a real application and ask it to trace how a specific behavior is implemented. The tool gained attention quickly, reportedly passing 100,000 GitHub stars within days of release, and has since generated a handful of public case studies where developers used it to study well-known software (an Android authenticator app, the Windows calculator, Notion, and QuickBooks Desktop) and then built their own independent tools informed by what they found.
The core idea isn’t cloning. It’s using an agent to read and explain code you didn’t write, so you understand the engineering decisions behind a piece of software well enough to make your own decisions when building something similar or different.
TL;DR
- REA connects AI coding agents to real installed software, letting them trace how a feature actually works instead of leaving you to guess from the outside.
- A developer investigated QuickBooks Desktop for Mac with REA and then built Ledger Reborn, an independent accounting app in Python and SQLite covering invoices, inventory, reconciliation, and cash basis reporting.
- A separate investigation into Notion’s clipboard system showed how copy and paste preserves rich block structure using an identifier embedded in HTML that reconnects to locally stored block data on paste.
- The Windows calculator percentage button case study is a small but sharp example: the same button produces different results after addition versus multiplication, because the app reads the current operation before deciding what the percentage means.
- The pattern across all four case studies is the same: studying a real implementation surfaces hidden requirements (edge cases, state dependencies, data formats) that a plain feature request to an AI agent would never capture.
- None of this requires you to already know how to code. The tool works as an accelerator for developers and as an explanatory layer for non-developers trying to understand what they’re asking an agent to build.
How did the QuickBooks investigation lead to Ledger Reborn?
A community developer used REA to study QuickBooks Desktop for Mac, focusing on a specific set of accounting mechanics: inventory arithmetic, budget assignment, reconciliation logic, balance calculations, and the branching logic behind cash basis reporting. Rather than guessing how double-entry bookkeeping edge cases should behave, the investigation let the developer trace how an established, widely used accounting product actually handles them.
The output was Ledger Reborn, an independently built accounting application written in Python with a SQLite backend. According to the developer’s published account, the app handles invoices, recorded payments, a local ledger, inventory tracking, and reporting, the same functional territory as the parts of QuickBooks they studied.
The significant part isn’t that someone built yet another ledger app. It’s the path they took to get there: instead of starting from a vague spec (“build me an accounting tool”), they started from observed behavior in a mature piece of financial software and worked backward to a design that could reproduce the behavior independently. Accounting software is full of rules that look simple until you hit a weird case (partial reconciliation, inventory valuation at the moment of a sale, how a refund interacts with a prior report). Those are exactly the kinds of details that don’t show up in a feature list but do show up in code.
What did the Notion clipboard case study reveal?
The Notion investigation starts with something every user does without thinking: copying a block of text. REA was used to locate Notion’s exposed clipboard interface and trace the surrounding code, including saved web editor code, to see how a copy operation preserves Notion’s richer block structure (not just plain text, but formatting, nesting, and block relationships).
What the investigation found: Notion writes both plain text and HTML to the system clipboard for compatibility with other apps, but it also keeps structured block data locally and embeds an identifier inside the HTML. When you paste back into Notion, that identifier lets the app reconnect the visible content with the saved structured data, as confirmed by a module test showing the rich block data returns when the identifiers match.
This matters beyond Notion specifically. Anyone building an app that needs copy and paste to preserve more than plain text (a note-taking tool, a research tool, a document editor) runs into the same design question: what travels with a copied item, and what gets reconstructed on paste? Before seeing a working implementation, “make sure copy and paste works” is a vague request. After seeing one, you can ask sharper questions: does the source citation travel with the quote? What happens if the original entry is deleted? Does an export need to carry more data than an in-app copy? Those are concrete technical requirements, not vibes.
Why does the calculator percentage button matter as an example?
Built like a system. Not vibe-coded.
Remy manages the project — every layer architected, not stitched together at the last second.
It’s a small case, but it makes the larger point cleanly. In the Windows calculator, typing 200 + 10% returns 220, while 200 × 10% returns 20. Same button, different output, because the correct meaning of “10%” depends on the operation that came before it.
The REA investigation into the installed calculator library traced the branch of code responsible for this: after an addition, the percentage button computes 10% of the first number and adds it; after a multiplication, it applies the percentage directly to the product. The button’s behavior is contextual, driven by whatever operation state the calculator is already tracking.
If you asked an AI coding agent for “a percentage button” without this context, you’d likely get a single, non-contextual calculation. It would look right in a demo and behave incorrectly the moment a user tried the same button after a different operation. Seeing the real implementation exposes the hidden state dependency that a surface-level feature description would miss entirely.
Is REA useful if you don’t know how to code?
Yes, and arguably it’s more useful for non-developers in a specific way. For someone who already writes software, REA answers a narrower question: how did they solve this, and can I move faster by reusing that approach? For someone who doesn’t code, REA does two different jobs. First, it helps you understand what your own idea actually requires technically, by letting you study how a related, already-built piece of software handles the same kind of problem. Second, it helps you understand why an existing implementation made the choices it made, so you can decide which of those choices belong in your own version and which don’t.
This matters because AI coding agents can now generate working code quickly, but they still need someone to specify what “working” means in detail. A request like “build me a note app” or “add copy and paste” sounds complete but leaves out dozens of decisions a real implementation has to make. REA gives non-developers a way to see those decisions laid out in actual code, discuss them with an agent in plain language, and arrive at a more complete specification before a single line of their own app gets written.
Is REA the same thing as cloning software?
No. The case studies described here are investigations, not copies. The QuickBooks and Notion examples involve tracing logic to understand a mechanism (how reconciliation balances work, how a clipboard identifier reconnects to stored block data), then building a separate implementation with a different stack and different design choices. The value is in the understanding transferred, not in reproducing someone else’s code wholesale.
Frequently Asked Questions
What is REA (Reverse Engineer Anything)?
It’s a tool that connects to AI coding agents such as Claude Code or Codex and lets them inspect installed software on your machine to explain how specific features or behaviors are implemented in the underlying code.
What is Ledger Reborn?
Ledger Reborn is an independent accounting application, built in Python with a SQLite backend, created by a developer who used REA to study QuickBooks Desktop for Mac’s inventory, reconciliation, and reporting logic before building their own version.
How does Notion preserve formatting when you copy and paste?
Other agents start typing. Remy starts asking.
Scoping, trade-offs, edge cases — the real work. Before a line of code.
Based on the REA investigation, Notion writes plain text and HTML to the system clipboard for compatibility, while also storing structured block data locally and embedding an identifier in the HTML so that pasting back into Notion can reconnect the copy with its original rich structure.
Do I need to know how to code to use REA?
No. The tool is described as useful in two distinct ways: developers use it to study and reuse implementation patterns faster, while non-developers use it to understand what a feature actually requires before specifying it to an AI agent.
Why did the Windows calculator percentage button become a case study?
Because it shows how the same UI control can mean different things depending on hidden state (the prior operation), a detail that’s invisible from the interface alone but obvious once you trace the actual code.
