Crash tests.
Real tasks. No afternoon skim.
AI tools tested against real business tasks and workflows, stress-tested beyond the
demo to reveal performance, limitations and test findings under defined conditions.
Real tasks. No afternoon skim.
Defined conditions. Past the happy path.
What breaks. What holds. What it takes to fix.
The verdict is never for sale.
Couldn't reach the repo or see a render, so build work needed a second tool.
One 6,000-word doc cut to its opening ~1,400 words.
One response had 3 of 8 citations fabricated.
The method gathers the evidence. A human makes the call.
Understand the product, its claims, intended use and initial experience. The tool meets a real task cold, with no prompt engineering and no setup coaching.
I stop right where a rushed user would stop. If the tool needs a manual to look competent, that's already the finding.
Apply realistic pressure and look for failure, friction, inconsistency, edge cases and the limits of what it can do.
Nothing fails on the happy path. I deliberately pick the messy, real project — the one I'd never volunteer for.
Preserve outputs, evidence, operator observations, unexpected behaviour, interventions and failures.
The evidence is the asset. Every number in the verdict traces back to something I logged.
Establish what holds, what fails, who it is useful for, its boundaries and what the evidence supports.
The number on the page is the number I'm willing to defend. If I can't defend it, it doesn't publish.
The thinking behind the tests — what a score alone can't tell you.