TL;DR: Inheriting a codebase — through an acquisition, a departed developer, or a finished contract — means you own a product whose reasoning lives in someone else's head. Reading the code line by line doesn't scale, and asking an agent to explain it gives you a confident answer you can't audit. What you need is a behavior-level map of what the product actually does, with every claim tied back to the code that proves it.
There's a particular kind of dread that comes with owning software you didn't write.
It arrives three ways. You acquired a small SaaS and the founder's handoff was a Loom video and a README. A developer left and took the only real understanding of the billing system with them. Or a contractor delivered "done," invoiced, and moved on — and now the product is yours to run, indefinitely, with no one to ask.
In every version, the situation is the same: there's a working product, real users depend on it, and you can't actually speak for it. You can open any file. What you can't do is answer a basic question — what happens when a subscription lapses, who's allowed to change this, why does this refund fire — without tracing it through code you've never seen.
"Read the code" doesn't scale, and "ask the agent" doesn't close it
The obvious first move is to read it. You'll get a few files deep before you hit the truth: reading code tells you what each function does, not what the product promises. You can follow the billing module line by line and still not know whether a lapsed subscription revokes access immediately or at the end of the cycle — because that's a decision, and decisions don't announce themselves in syntax.
The second move, in 2026, is to point an agent at it. Ask Claude Code or Codex to "explain this repo" and you get a fluent summary in thirty seconds. It feels like progress. But for inherited code it's a trap dressed as a shortcut. The summary is reconstructed from the same code you can't yet trust, stated with the same confidence whether it's right or wrong, and gone the moment the session closes. You can't attach it to a valuation. You can't hand it to a new hire as ground truth. You can't audit it — and auditability is the entire point when the stakes are "I now own this."
A summary you can't check is just a more articulate version of not knowing.
What you actually need
Not a wall of code, and not a paragraph of vibes about it. You need a map at the level decisions actually live — the level of behaviors. What the product does, grouped by what it's for: the auth behaviors, the billing behaviors, the integration behaviors. And critically, every claim on that map tied back to the specific file or function it was traced from, so you can verify it instead of trusting it.
This is the same shape as a behavior spec, except you're not authoring it from intent — you're recovering it from a product that already exists and is already yours. The answers are sitting in the code. The work is reading them out into something you can hold.
The move, when the code isn't yours
You don't have to understand everything. You have to understand the things that would hurt.
Start worst-first. Billing, auth, entitlements, anything touching money or access. Map the four or five behaviors where being wrong is a refund, a breach, or a furious customer — not the whole repo.
For each one, recover three things: what must happen, what must not, and the edge cases that matter. Inherited code adds a fourth, harder question to every behavior: is this a decision, or a default someone left in? The previous owner made real choices and also let accidents calcify into "how it works." You can't tell which is which until you lay the behavior next to its evidence and look.
Then write down what you find — as an artifact, outside any agent's context window, in product terms, tied to the code. That artifact is what makes the knowledge yours. It's the thing you brief a new developer with, the thing you attach to a due-diligence file, the thing your next agent session reads instead of re-guessing the previous owner's intent.
For an acquisition, that last point is the difference between gambling and investing. An evidence-linked map of what you're buying — including the risks nobody disclosed, like the path where a user can escalate their own role — is something you can put a number against. A demo and a good feeling are not.
What you get back
You get to answer the support email without spelunking. You get to make a roadmap decision without fear that you'll break a behavior you didn't know existed. You get to walk into a partner call and describe what your product commits you to. You stop avoiding the parts of your own product that someone else wrote.
Inheriting a codebase makes you the owner on paper the day the deal closes. Reading it — behavior by behavior, against the evidence — is how you become the owner in fact.
I built Stewie Reflect for exactly this moment. Point it at a snapshot of the repo and it writes an owner's manual for the product inside — every behavior in plain language, every claim linked back to the file or function that proves it, the risks worth your attention surfaced, and the gaps flagged honestly as gaps. It's read-only and never runs the code. It won't make the owner's calls for you — that's yours now — but it lays the evidence out behavior by behavior, so understanding a product you didn't build is a morning's work instead of a month of archaeology. Run it on the repo and see what it surfaces.
