Three Systems, One Document, and the Same Flaw at 12:45 AM

At 12:45 in the morning, the first review came back in three minutes: the funnel has no top. At 12:47, a second reviewer, working from the same document, took four and a half minutes and returned a review dense enough to run tens of thousands of tokens on the same underlying problem. At 12:56, a third reviewer, given nothing but the document and no knowledge of what the other two had said, took almost fourteen minutes and wrote: “Do not lead with MCP or cross-vendor portability. Both are materially less validated than the strategy assumes.”

That was three different AI systems reading one document on one night, and none of them saw each other’s answers. All three landed on the same flaw. We had built something on assumptions about how customers behave that nobody had checked with an actual customer.

The document that looked finished

The document was our positioning plan for this blog, dxdev.com. It was not a memo. We had built it out close to the real thing: the path a visitor would take, the case studies meant to prove the point, and the pitch about why a swappable AI engine mattered to a reader. It read like a finished plan, tangible enough that you could hand it to someone and they would believe it was already decided. A prototype that looks finished starts to feel true.

We had already spent real hours on it before any review landed. That was the cost. No money went out the door. The hours went into making a plan convincing before checking whether the thing it convinced people of was correct.

What “no top of funnel” meant

The first reviewer’s line sounds abstract until you translate it. The plan assumed people read the blog first and then discover what we sell. Nobody had confirmed that path was real. We had put case studies at the top of that funnel, and the reviewer’s point was that we were treating a guess about reader behavior as settled fact and building the rest of the pitch downstream of it.

The third reviewer’s point about MCP and cross-vendor portability had the same shape from a different angle. We had a technical fact that sounded like a selling point: the system is not locked into one AI vendor and can run on whichever works best. That interested us. Nobody had confirmed that a customer deciding whether to hire us cared about it at all, let alone enough to make it the headline.

So there were two separate technical claims and two separate reviewers, with one shared root cause. We had confidence where we had no evidence.

Why three independent readers mattered

Had we sent the document to one reviewer, we would have gotten one opinion and a plausible reason to argue with it. Three systems with no view of each other’s work converged on the same complaint, using different words and different examples. Asking the same question twice and hoping for a different answer does not produce that. Asking three independent readers “what’s wrong with this” at the same time, and seeing whether they land in the same place, does.

They did land in the same place. We stopped building the prototype that night. The plan had been to keep filling in the funnel with more case studies and more pages. Instead we shelved it and went back to something slower and less satisfying: asking actual people, by hand, whether the assumptions in the plan were even close to true, before writing one more page that depended on them.

The prototype was persuasive before it was tested, and persuasive is exactly the quality that makes you stop checking. Before building further on a plan, ask actual customers whether its core assumptions hold.

dxdev LESSON · paste into your AI coding agent
LESSON: A Persuasive Prototype Is Not a Validated One
SOURCE: dxdev.com/blog/prototype-validation-over-build
WHAT HAPPENED: A positioning plan for a new product direction was built out into a clickable prototype, case studies included, before any of it had been checked against a real customer. It looked and read like a finished decision. Run past three independent AI reviewers at once, with none of them able to see the others' output, all three converged on the same root cause from different angles: the plan assumed things about customer behavior and buyer priorities that nobody had confirmed with an actual person. The team stopped building the rest of the prototype that night and went back to validating the assumptions by hand with real businesses first.
THE RULE: A prototype or pitch that is tangible and well-produced is persuasive regardless of whether the assumptions underneath it are true, and persuasiveness is exactly the quality that makes people, including the person who built it, stop checking. Before investing further build time in a plan, ask what customer-behavior or buyer-priority assumption it depends on that has never been confirmed with a real person, not just reasoned about internally. Running the same document past multiple independent reviewers with no visibility into each other's answers is a cheap way to tell a real, convergent problem from one reviewer's individual opinion.
CHECK MY CODE, then report PASS or FAIL with file:line for each:
  1. Any product plan, pitch deck, or prototype that has reached a polished, presentable state without a documented check against a real customer or user's actual behavior.
  2. Any headline claim or selling point in a positioning document that rests on an internal technical fact (an architecture choice, a vendor relationship) rather than on confirmed evidence that a buyer cares about it.
  3. Any review process for a strategic document that routes to a single reviewer rather than multiple independent ones, making it impossible to tell a convergent finding from one opinion.
THEN PRINT: a table (check, PASS/FAIL, evidence, fix) + a verdict (applies / partially / OUT_OF_SCOPE / no) + the single most important next action.