You vibe-coded an MVP and skipped the spec. Here's how to rebuild it.

Someone posted this almost sheepishly: they'd vibe-coded a few apps to MVP, were happy with them, then realized they'd done it "the wrong way" — no spec, just prompts and a working thing. Now they wanted to construct a PRD from the code they'd already written. The replies argued terminology (PRD vs. technical design doc) and missed the real need.

The need is real and increasingly common: you have a working product and no document that describes what it does. That's not a failure. It's just the order things happen now — build first, understand later. The question is how to recover the understanding.

Why reverse-spec beats starting from a blank doc

The usual advice — sit down and write the PRD you should have written — has a fatal flaw. You'll write the PRD for the app you think you built, not the one that exists. Every assumption you made while building gets baked in again, because you're the same person interpreting the same mental model. You'll miss the same edge cases.

A spec built from the running product starts from reality. What does this button actually do? What happens on this error path? What state does the app end up in when the user does the weird thing? The behavior is ground truth, and a spec derived from it describes what's real, not what you intended.

The pipeline, in order

1. Map what's actually there. Walk the product — every screen, action, state. Catalogue the actors, triggers, and effects: who can do what, what kicks it off, what happens as a result. You can't spec what you haven't inventoried.

2. Reconstruct the flows. Connect the inventory into the real paths users take. The gaps start showing here — the half-finished branch, the error that dead-ends, the feature wired up on the backend but never surfaced.

3. Run gap analysis. Compare the flows against what a coherent product should do. The cross-midnight case that splits wrong, the permission checked in one place and not another — the stuff you'd never catch reviewing your own code, because you read it the way you wrote it.

4. Write requirements from the resolved flows. Now the spec describes the real, gap-checked product — including the parts you're choosing not to fix, documented as known limitations instead of silent landmines.

5. Derive test cases. The spec implies what should be true. Generate the cases, run them against the real product, find where shipped reality diverges from documented intent. That divergence is your punch list.

The thing nobody tells the vibe-coders

You didn't do it wrong. You did it in the order the tools now allow. The mistake isn't building before specifying — it's staying in the no-spec state, where every future change is a guess and every handoff loses context. The reverse-spec exists so you can keep moving fast without flying blind.