TL;DR: The night before launch, the scary part isn't whether the product works — it works. It's that someone is about to ask you what it does, at the edges, in front of an audience, and you'd have to open the file to answer. You can't launch a product you can only read. The fix isn't more polish; it's closing the gap between what shipped and what you can speak for.
It's the night before you launch. The product works. The deploys are green, the demo path is smooth, the landing page is up. By every visible measure you're ready.
And you're sitting there quietly terrified, because tomorrow someone is going to ask you a question you can't answer.
Not a hard question. A normal one. "What happens if I sign up with the same email twice?" "Does the free tier expire, or just cap?" "If I cancel mid-month, do I keep access until the period ends or lose it immediately?" The kind of thing a Reddit AMA, a YC office-hours partner, or the first real customer asks in the first five minutes. And the honest answer is: you'd have to go open the file to find out.
The gap nobody warns you about
Everyone warns you about the bugs. Nobody warns you about this.
You built the product fast — Claude Code, Codex, Cursor, whatever's in your loop wrote most of the implementation, and it wrote it well. That's not the problem. The problem is that the product grew past your understanding of it while the deploys stayed green. You can still read any single file. What you can't do is speak for the thing without reading every file first.
I've called this shipping a stranger — the daily version, where a user emails and you open the file to answer. Launch is the magnified version. Instead of one email you can quietly answer later, it's a live audience, a recorded demo, a thread with your name on it, and the question lands in real time. The gap that was a private inconvenience becomes a public one.
"Launch" is more than launch day
The trap is thinking this is a one-night problem you can cram for. It isn't, because launch isn't a single day. It's every moment where you have to account for your product to someone who's deciding whether to trust it.
The press demo is a launch. The YC office-hours grilling is a launch. The Reddit AMA is a launch. The enterprise prospect's security questionnaire is a launch. The partner integration call where their engineer asks "what does your API actually guarantee here?" is a launch. The investor who asks, mid-pitch, "so what exactly does the product promise the user?" — launch.
Every one of those is a moment where the product works is not the question on the table. The question is whether you know what it does. And you can't cram for all of them the night before, because they don't happen on a schedule you control.
You can't read fast enough to fake it
The instinct is to fake it — skim the code the night before, build a mental cheat sheet, hope the questions land where you looked. It doesn't hold, for two reasons.
First, you don't know which behaviors they'll probe, so you'd have to hold the whole product in your head at once — exactly the thing that became impossible the moment the agent started shipping faster than you could absorb.
Second, the dangerous answers aren't the ones you decided. They're the ones you never decided — the agent picked a default, it shipped, it became canon, and you've never once looked at it. "Does a failed payment retry or just lock the account?" You don't have a wrong answer to that question. You have no answer, because that behavior was never a decision you made. It's an accident you're about to defend on stage as if it were a choice.
"Just ask the agent before the demo" isn't the fix
The obvious move: have the agent that wrote the code explain it to you an hour before. Ask Claude Code or Codex to summarize what your product does, read it on the way to the call.
It doesn't close the gap. A summary you scrolled past at 11pm isn't knowledge you can defend at 9am under questioning. The agent gives you a fluent reconstruction — assembled from the same code, confident whether or not it's right, and gone the moment the session ends. It reconstructs; it doesn't commit anything to you. The next time you need it, it's gone, and you're skimming again. Under a follow-up question — "wait, are you sure?" — a summary you don't actually hold collapses immediately.
What survives a launch is understanding you hold: the decisions written down as their own thing, in product terms, tied back to the code that proves each one. Something you read once, recognize, and can stand behind because you've already made the call. That's the same shape as a behavior spec — except before launch you're not inventing it, you're recovering it from a product that already exists and deciding, behavior by behavior, whether what shipped is what you meant.
What "ready" actually means
Ready isn't a green deploy. The deploy was green a week ago. Ready is the moment you can sit in front of anyone — a customer, a partner, a room of strangers — and answer "what does it do at the edges?" without reaching for the file.
You get there the same way out of the gap as everyone else: worst-first. The three or four behaviors where being wrong on stage would actually hurt — billing, auth, entitlements, whatever carries real consequences. Recover what each one does, decide whether it's what you intended, and write the answer down where you can find it before the call instead of during it.
The product was ready to ship a while ago. The question launch actually asks is whether you're ready to speak for it. Vibe-coding got you a product fast. Closing this gap is what turns "it works" into "I can stand behind it" — which is the only version of ready that survives a launch.
I built Stewie Reflect for exactly this moment. It takes a snapshot of your repo and writes an owner's manual for the product inside it — every behavior in plain language, every claim linked back to the file or function that proves it, and the edges flagged honestly as edges. It's the thing you read before the demo so you're not opening files during it. It won't decide what your product is supposed to do; only you can. But it lays out what it currently does, behavior by behavior, so "ready to launch" stops meaning "the deploy is green" and starts meaning "I can answer the question." Run it on your repo before your next launch — whatever counts as launch for you.
