I built the boring half of an AI tool everyone else skipped

Every spec I wrote read fine. Clean, confident, signed off. Then a sprint in, an engineer would ping me: "what happens if the payment fails halfway?" And I wouldn't have an answer, because that case was never on the page. Not wrong, just absent. The doc looked done and was quietly broken.

For makers who haven't lived in PM-land: a PRD (product requirements doc) is the spec an engineer builds from. The failure mode isn't bad writing. It's the gap. The acceptance criterion you didn't write, the edge case nobody mapped, the empty state you forgot existed. None of it shows up when you reread your own draft, because you already know what you meant. So the first real review happens later, out loud, in a meeting, when changing course is expensive.

I leaned on AI for a while and it made things worse in a sneaky way. Ask a model to improve your spec and it polishes what's already there. Tighter sentences, nicer headings. It flatters the page. It almost never says "you never defined what happens when this fails." Writing tools optimize for what exists. The whole problem is what doesn't.

Then the obvious thing hit me: writing specs is taught everywhere, reviewing them is taught nowhere. I was never shown how to red-team my own doc. Most PMs aren't. We learn to produce, never to interrogate. So the build wasn't "another AI that writes PRDs." It was the reviewer.

I sat down and wrote out what a good senior reviewer actually checks, the questions they ask that I'd been answering too late. It came to eleven distinct passes: is the context clear, is the thing actually complete, can engineering build it, are the user flows covered, where are the edge cases, what breaks. Each finding lands as a comment on the exact line it's about, tagged blocker, major, or minor, with a suggested rewrite. It ends on a 0 to 100 score, deterministic, same spec, same number, not a model's mood that day.

The decision I'm proudest of, and the one I want to put to this community: I published the rubric. All eleven checks are visible before you pay. You can audit exactly what it looked for and argue with it. My bet is that a tool naming its checks teaches you the checks while it runs them, the way a good code reviewer's comments make you a better engineer. And it's a thing incumbents structurally won't copy, because their pitch depends on the mystery. A black box just hands you a verdict and teaches you nothing.

I also stopped pretending I win on everything. There's a cheaper, all-in-one competitor, and for someone who just wants fast generation, they're the better buy. I say that on the site. Conceding the case you lose makes people believe you on the case you win.

The lesson I keep coming back to as a maker: the valuable product often isn't the thing everyone automates (generation), it's the unglamorous step they skip (review).

If you want to see the eleven checks, they're at [usethinkr.com](https://usethinkr.com).

Genuine question for the room: when you've built a tool that judges a user's work, did you expose your criteria or hide them, and which one actually built trust?