DEV Community: Demilade Ayeku

Most "X vs Y" Developer Content Wouldn't Survive a Real Build

Demilade Ayeku — Tue, 30 Jun 2026 09:57:50 +0000

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. 🥑

What I Thought DevRel Was vs. What It Actually Is (A Mentee's Honest Take)

Demilade Ayeku — Mon, 25 May 2026 11:20:40 +0000

A few weeks ago, if you'd asked me what "DevRel" stood for, I would've squinted, smiled, and given you a confident-sounding non-answer. Today I'm in a DevRel mentorship program so let me close that knowledge gap for you the way it got closed for me

The "Before": What I Thought DevRel Was

When I first heard the term Developer Relations (DevRel), my brain did what most people's brains do; it grabbed the two words and built a half-decent guess.
"Oh, so… you relate to developers? Like, customer support for developers?"

Not quite.

I also assumed it was basically being a tech influencer. Someone who posts on Twitter/X, shows up at events with a branded hoodie, and tells everyone how amazing their company's product is. Half marketing, half cheerleader.
Also not quite.

The "During": What DevRel Actually Is

Here's the cleanest definition I can give you:
DevRel is the bridge between a company that builds tools for developers and the developers who actually use those tools.

Think of it like this: imagine a company builds a really powerful kitchen appliance, but only professional chefs can figure out how to use it. That appliance will flop; not because it's bad, but because nobody knows how to get value out of it. DevRel is the team that writes the cookbook, hosts the cooking class, listens to chefs complain about the buttons, and then walks back to the engineers and says, "Hey, can we move this button?"

In tech, that "appliance" is usually an API, an SDK, or a developer tool. The "chefs" are software developers around the world. And DevRel is the function that makes sure the two actually connect.

One thing my mentor said in our first session that stuck with me:
"You should be a developer(Even at beginner level) before you become a developer advocate."

This is the part that demolished my "tech influencer" theory. You can't honestly bridge two worlds if you only live in one of them. If you've never written code, you don't know which parts of a product are confusing, broken, or magical. You can talk to developers, but you can't speak with them.

The Three Cs of DevRel
The work itself breaks down into three pillars what folks in the field call the 3 Cs:
🧑🏽‍💻 Code — DevRel folks build things. They use the product themselves, ship demo apps, write sample code, and feel the same friction real developers feel. This is how they earn the right to speak.
✍🏽 Content — They turn the product into something learnable. Documentation, tutorials, blog posts, videos, livestreams, conference talks. If you've ever Googled "how to do X with [some tool]" and landed on a guide that actually made sense; that was probably DevRel's work.
🤝🏽 Community — They show up where developers gather. Hackathons, meetups, conferences like DevFest Lagos, Discord servers, Twitter/X spaces. They're not there to sell; they're there to listen, teach, and build genuine relationships.
A DevRel person who only does one of the three? good but can be better. A DevRel person who weaves all three together? That's the real job.

The "After": How I'm Actually Getting Started

I won't pretend I've figured this out. I'm at the very beginning; accepted into a mentorship program. But here's what "getting started" looks like in practice:

Becoming a developer first. Not optional. Before I can advocate for developers, I need to be one, even at a beginner level. Code is the foundation that everything else stands on.
Learning from people already doing it. A few I'm watching closely:
Tejas Kumar — chief developer advocate, podcast host, and one of the clearest voices on what DevRel actually is and isn't. His ConTejas Code podcast has a whole episode dedicated to a deep dive into DevRel.
Sodiq Akinjobi — Developer Ecosystem Community Manager at Google and one of the organisers behind GDG Lagos and DevFest. If you want to see community-building done well in Africa, watch what he ships.
Joshua Omobola — a true polymath whose work cuts across engineering, writing, and community from Supertokens to Web3Afrika. The kind of multidisciplinary profile that DevRel rewards.
Timonwa Akintokun — DevRel Engineer at IQ AI, working on ADK-TS (the Agent Development Kit for TypeScript). She literally sums up the job on her site as "Code, content, and community that's what I do." Iconic. Also, a reminder that this field has space for women doing absolutely cracked work, and the more visible that is, the better.
Putting myself out there. Which is what this blog post actually is. Writing in public is one of the best things you can do, you're practising content, learning to explain, and inviting feedback at the same time. (This is me practising.)

A Quick Word on Career Paths

DevRel isn't one job; it's a family of jobs. You can specialise as a Developer Advocate, a Technical Writer, a Community Manager, a Developer Experience (DX) Engineer, or a DevRel Engineer. Some lean more toward code, some toward content, some toward people. There's no single ladder, which is intimidating at first but freeing once you accept it.

So… What Do You Take From This?

If you're a fellow developer wondering whether DevRel could be a fit, it is if you like teaching and you don't mind being visible.
If you're non-tech and you've read this far, congratulations! You now understand a corner of tech that even a lot of tech people don't fully get. The next time someone says they work in DevRel, you'll know they're not doing tech support, and they're not just an influencer. They're the bridge.
And if you're somewhere in between, welcome to the club. I'll see you out there!

This post is part of my journey through the DX mentorship program. I'll be writing more as I learn. Feel free to follow along, or share your thoughts in the comments on what you thought DevRel was before reading this. I'm collecting answers!🥑