Teach, don't market: our content strategy in public

Someone asked me last week why this blog reads like a lab notebook instead of a landing page. Fair question. Here's the real answer instead of the one that sounds good in a pitch deck.

"Teach, don't market" isn't a value we hung on a wall somewhere. It's a small set of editorial rules that decide what we're allowed to publish, and they've already cost us posts we could otherwise have shipped this month. This is a post about a developer content marketing strategy, which is a funny thing to write a post about, because the strategy's whole point is that it doesn't read like marketing. Let me show you the mechanism instead of just claiming that.

What "teach, don't market" means, operationally

Say the phrase out loud and it sounds like a fortune cookie. Strip the slogan off it and what's left is a set of constraints that make certain posts impossible to write, or at least impossible to write fast.

We already argued the biggest one in public. Why we won't write "Chiplab vs" pages makes the case that comparison pages are the best-converting content type in SaaS, and we're still not writing them, because there's no incumbent search volume in "MCU simulation for coding agents" to intercept yet. Nobody types "Chiplab vs" anything. Writing that content now wouldn't be marketing, it'd be talking to an empty room and calling it strategy.

Before we'd let ourselves write comparison content at all, we ran an audit on what already ranks for the queries a firmware engineer would actually type. That audit found the top-ranked embedded simulator comparison on the internet listing Renode's license as Apache 2.0. It's MIT. One word, in a file named LICENSE, at the root of the repo. Whoever wrote that table didn't open the project. We didn't earn the right to publish comparison content by declaring ourselves trustworthy. We earned it by going and checking what the competition actually got wrong, in public, before writing a single row of our own.

That's the operational part. Not "be honest" as a stance, but a checklist that has to pass before a post ships: is there a real audience for this yet, did we check the thing we're about to contradict, and are we citing the primary source or somebody's summary of it.

The rules, plainly

Four of them, and none require a philosophy degree to check:

Cite primary sources, not secondary aggregators. If a claim rests on a license, a spec, a paper, or a benchmark, we go read that thing, not a blog post summarizing it. The comparison audit above exists because the top search result for "embedded simulator comparison" clearly didn't do this. Copying a wrong number is faster than checking it. It's also how a wrong number gets a second life.

Run real Chiplab instances rather than describe hypothetical behavior. If a post says firmware booted, ran to completion, or printed specific output, that output came out of a real run against a real target, not a plausible paragraph about what would probably happen. This is the single most expensive rule on the list, and I'll get to why in a minute.

Admit when the tool has a limitation instead of hiding it. Somewhere in this same batch of posts, the datasheet-to-firmware writeup hits a real limitation mid-experiment and reports it instead of quietly editing the post to route around it. That's not generosity toward the reader. It's the only version of the post that survives someone else trying to reproduce it.

Don't force product mentions into posts that are fundamentally research or commentary. Most of what we publish doesn't need Chiplab's name in it to be worth reading. When a post is about how Renode and QEMU each model hardware, or why HIL doesn't scale for AI-generated firmware, the product shows up when it's the tool that actually did the work, not because someone on the marketing side asked for a mention count.

None of these rules are about being a nicer company. They're about what's allowed to get past "is this true" before it gets to "is this useful."

Why this is also just good SEO, and not altruism

I want to be direct about the self-interest here, because pretending there isn't any is its own kind of dishonesty.

Developer content has a verification step baked into it that most B2B content doesn't: developers run the code, check the datasheet, or open the repo. That audience trait is exactly why the license mistake in the comparison audit mattered as much as it did. One wrong cell in a feature table isn't a rounding error to a firmware engineer, it's proof nobody on the writing side opened the thing they were writing about. And once a reader catches one wrong fact, they don't discount just that fact. They discount everything else on the page, including the parts that were right.

That asymmetry is the whole argument. A missing feature costs you a maybe. A wrong fact costs you the reader's willingness to believe the next five true things you say. Given that trade, checking the primary source isn't a virtue, it's the cheaper mistake to avoid.

This batch you're reading a post from is itself the evidence, not just the claim. Ten posts, each one anchored to either a fresh Chiplab run or a checked primary-source citation instead of a plausible-sounding paragraph, written against a shared brief that rules out invented benchmarks and vague claims before a single word gets published. That's not a promise about our intentions. It's a description of how this specific set of posts, including this one, got made.

What it costs

Here's the part that doesn't make it into most "we value honesty" posts: this is slower, and it's slower in ways that show up on a calendar, not just in principle.

Running a real Chiplab instance against a real board target takes longer than writing "Chiplab handles this" and moving on. Reading a paper closely enough to cite its actual finding, instead of the finding you assumed it had, takes longer than pattern-matching on the abstract. Opening a competitor's repository to check a license field takes thirty seconds, which sounds trivial until you're doing it across every comparison claim in a post and the thirty seconds multiplies by twenty.

Multiply that across a ten-post batch and the difference stops being rounding error. A post written from vibes can ship the same afternoon it's drafted. A post anchored to a real run has to wait for the run, then get checked against what the run actually produced, not what the outline assumed it would produce. That gap is the tax. We're paying it on purpose, but it's still a real cost, and I'd rather say that out loud than pretend the rules are free.

Still marketing, just refusing to lie to get there

I'm not going to pretend this is something other than marketing, because it obviously isn't. You are reading this because we want you to trust Chiplab enough to try it, and every post in this batch is, underneath the citations and the run outputs, aimed at that same outcome. Calling it "teaching" doesn't change who's paying for the writing or why it exists.

What it changes is the method. We don't get to invent a benchmark to make a point land better. We don't get to describe a run we didn't actually make. We don't get to leave a competitor's license field wrong because checking it is thirty seconds we'd rather not spend. The audience is still deciding whether to trust us. The rules just take away the option of lying to speed that decision up.

And we will get things wrong sometimes, because every editorial process run by humans and agents checking each other's work eventually lets something through. When that happens, the fix is a correction, not a rewrite of history. A blog that never admits a mistake either hasn't made one yet, which is unlikely at this volume, or isn't telling you when it does. We'd rather be the kind that says so.

If you came here looking for a reason to believe the last nine posts weren't just well-formatted guessing, this is it: the rules are the same ones that produced the post that questions Renode's own foundation, the post that calls out a competitor's factual error by name, and the one that admits our own tool's limitation in the middle of an experiment we ran specifically to find it. That's the strategy. Everything else is execution.