The problem with most comparison content
If you've ever searched "Solana vs Sui" or "Drizzle vs Prisma" or "Polars vs Pandas," you know the shape of what comes back.
A clean feature table. A vague "best for" paragraph at the bottom. Maybe a chart of GitHub stars. And nothing in it would help you make an actual decision.
That's because most "X vs Y" content is written from documentation. Not from builds.
A writer opens both sets of docs, extracts the feature lists, organises them into a table, and adds enough hedging that no vendor gets upset. The post ranks. It gets cited. And it leaves the reader exactly where they started, except now they think they've done their research.
In a recent DX mentorship session, William Imoh (founder of HackMamba) walked us through why this matters more right now: comparison content is the AEO wedge. When a CTO asks ChatGPT or Perplexity "which of these tools should I use for X", the model surfaces whatever comparison content best answers the question. The comparisons that win citations from AI assistants are not the ones with the prettiest tables. They're the ones with the most specific, evidenced answers.
Which means we have an honest content gap and the people who can fill it aren't writers. They're builders who write.
The Comparison Test
Here's the test I run on any "X vs Y" piece I read now. Four questions. A piece that passes all four is rare, and worth bookmarking. A piece that fails any of them is decoration.
- Did the author actually ship something end-to-end on both sides?
Not a hello-world. Not a sample app cloned from the README. Something that has a real user flow, real state, real failure modes. If they only built on one side and read about the other, the comparison is theatre.
You can usually tell within two paragraphs. Real builds produce specific complaints about toolchain bugs, missing primitives, weird gotchas in the deployment story. Doc-readers produce generalities "developer-friendly," "well-documented," "growing ecosystem."
- Can they name a bug they hit on each side?
This is my favourite question because nobody can fake it. If you genuinely shipped on a tool, you have stories. The 3am moment when something compiled fine but produced wrong output. The version mismatch that ate two hours. The undocumented edge case in the SDK.
A comparison post with no bugs in it is a marketing document. A comparison post that names two bugs one per tool is a signal that the author actually wrestled with both.
- Do they tell you which one not to use, and when?
The cleanest tell that a comparison is honest. Most posts are scared to say "don't use X if you're doing Y" because they want to stay friends with everyone. But that's exactly the recommendation a reader needs.
Honest comparison content has opinions that could cost the author a partnership. That's the entry fee.
- Would the author's recommendation change if the reader's stack was different?
This one separates the thoughtful comparisons from the merely opinionated. A real builder knows that "X is better than Y" is almost never true in isolation, it's true for a specific stack, team size, scale, or workflow. A good comparison helps you locate yourself on the map, not just pick a winner.
If a post recommends the same tool to a solo founder and to a 50-person engineering org, the author isn't thinking carefully enough.
Why this matters more in the AEO era
The shift William named in our session that content now has to be cited by AI assistants, not just ranked on Google changes the economics of comparison content in a specific way.
Google rewarded coverage. A long comparison post with all the keywords could rank even if the actual analysis was thin. AI assistants reward specificity. When Perplexity is generating an answer to "should I use Drizzle or Prisma for a small team building an API," it needs to extract a specific recommendation grounded in specific reasoning. Vague comparison content gets passed over because the model can't pull a clean answer from it.
The result: comparison content written by people who've actually shipped is going to start outperforming comparison content written from docs, because the former has the specific evidence the model needs to cite.
Which is funny, because for years the incentive was the opposite. Doc-readers could spin up volume. Builders were too busy building. AEO inverts that,the build is the moat.
What this means if you build in public
If you're a developer who ships across multiple ecosystems — even informally, even just at hackathons, you already have raw material that most content marketers don't.
Every multi-chain project you've shipped is a comparison post you haven't written. Every time you tried a new framework and bounced off it is a "Why I moved from X to Y" piece you haven't written. Every time you debugged something at 3am on one platform that worked first-try on another is a paragraph that would beat a thousand feature tables.
The bar for AEO-grade comparison content isn't writing skill. It's specificity. And specificity is just the residue of having built.
A small invitation
I'm going to start writing more comparison content from inside my builds; multi-chain stuff first, since that's where most of my recent work has been. If you've shipped on multiple competing tools and have honest opinions about which one to use when, I'd genuinely love to read what you'd write.
Drop the URL of an "X vs Y" comparison you've actually read and trusted in the comments. I'm collecting examples of comparison content that passes the test, for my own reference and for anyone else trying to write it.
This post builds on a session with William Imoh in the DX mentorship program (founded by Ekene Eze). The comparison-as-AEO-wedge framing is his. The Comparison Test is mine. 🥑
Top comments (1)
I would appreciate more insights and even resources!!!