I’ve been writing a newsletter for about three years.

But that number is misleading. I started it eight years ago, sent maybe seven or eight issues, then went quiet. The newsletter eventually became the official AsyncAPI newsletter and other people maintained it for years, sending monthly updates while I worked on the spec itself. Last year I split off my own version to write what I wanted to write. That’s the part that’s been running consistently. About one year of real, regular writing. The rest was starts and stops.

By any reasonable definition of “building an audience,” I should not have one. I didn’t post regularly. I didn’t have a content calendar. For long stretches I didn’t write at all. And yet the audience exists. Most of the people who subscribed during the AsyncAPI years are still here, even though I’m now writing about hustle culture and burnout instead of event-driven architecture.

This is the part most newsletter advice gets wrong. The advice talks about funnels, content calendars, lead magnets, growth hacks. Almost none of it would have produced what I actually have. What I actually did was much simpler and much harder.

I did real work in public for a long time. The newsletter was just one of the surfaces it lived on.

That’s the whole strategy. I don’t have a more clever version. The audience came as a side effect of the work, not as a result of trying to attract it. And the work, to be clear, was not the newsletter. The work was AsyncAPI (the spec, the community, the GitHub repos, the talks at conferences, the docs, the years of slow, mostly invisible engineering effort). The newsletter was where I occasionally wrote about what was happening. People who cared about the work paid attention to whatever surface it appeared on.

But there are a few things I’d do differently if I were starting today, in 2026, as an engineer with zero audience. Most of them are about not making the same mistakes I made.

The mistake I keep wanting to undo

The biggest one: I spent a lot of time trying to grow the newsletter through social media.

Social media is a kitchen sink. It devours your time and gives very little back. The platforms are engineered to become addictive using variable rewards. They show you a great post, then a mediocre one, then a great one again, just often enough to keep you scrolling. The same mechanism applies when you’re posting. Every post is a small bet. Most of them lose. The few that win release a hit of validation that keeps you coming back.

It’s the tech representation of a toxic relationship. You spend hours there, you feel worse, you tell yourself this time will be different.

For the actual newsletter, social media did almost nothing. The handful of times my work spread far on social, it spread because someone with credibility shared something I’d already written. Not because I’d posted thirty times that week. The work was the asset. Social was the rumor.

If I were starting today, I’d post much less. I’d treat social as a place to be findable, not a place to perform. A few good posts a month, written without performance anxiety, are worth more than daily LinkedIn theater.

What actually worked

The thing that built the audience wasn’t strategic. It was just: I was writing about something I cared about, the thing kept getting more interesting, and I kept sharing what I learned.

The first piece of mine that spread beyond my own circle was a release update for AsyncAPI 1.1.0. Strangers shared it on Twitter back when Twitter still functioned. I didn’t write that update to grow my audience. I wrote it because there was a new release and people who used the spec needed to know about it. The fact that it spread was a side effect of being useful to a specific group of people.

That’s the pattern that worked, repeated for years. Write something useful for a specific group of people. Make it findable. Repeat.

The thing nobody tells engineers is that the bar for “useful” is much lower than you think. You don’t need to write the definitive guide. You need to write the thing you keep explaining to colleagues. The thing where you find yourself saying “wait, let me show you” five times a week. Those are the topics that don’t have good public resources, and the explanation you give your colleagues is already most of the way to a publishable piece.

If you’re an engineer reading this and thinking “but I have nothing interesting to write about,” you’re judging your work against an imaginary audience of general tech enthusiasts. That audience doesn’t exist. The audience that exists is engineers who do something close to what you do and want to do it better. They’re starving for what feels normal to you.

The pieces that worked best

Two issues I’ve written got disproportionate response.

The first was about accepting a job at Hookdeck and leaving three weeks later. People wrote back to that one in numbers. The pattern in their replies was admiration mixed with relief. Admiration because admitting you failed publicly while quitting a perfect job takes something most professionals will not do, and relief because they recognized themselves in the situation but didn’t think they were allowed to act on it.

The second was an issue called “From burnout to a 4-hour workday.” That one got me real friendships. Marc, one reader and I met in Barcelona after exchanging emails. We’re still in touch.

What both pieces have in common: they were honest about something most engineering writers don’t write about. The work was inside me, not inside the technology. They weren’t tactical. They didn’t have actionable bullet points. They were specific stories that named a thing readers were already feeling but didn’t have language for.

I’m not saying every newsletter should pivot to memoir. I’m saying the pieces that traveled furthest were the ones where I said something true that I hadn’t seen anyone else say. That’s also the pattern worth copying. Not the topic. The willingness to write the specific true thing.

What I’d do differently in 2026

If I were starting a purely technical newsletter today, with everything I’ve learned, here’s what would change.

I’d write shorter pieces. Fewer 2,000-word deep dives. More 500-word pieces that scratch a specific surface and then stop. The instinct to write long is usually about the writer’s anxiety, not the reader’s needs. Long pieces feel important to write. Short pieces are easier to read and easier to share.

I’d go deep in one specific thing rather than broad across many. The engineers who built audiences I respect, each own a specific lane. They’re not generalists trying to cover all of tech. They’re specialists who got known for one thing and then expanded outward from a position of authority. Trying to be a generalist from zero is a slower path.

I’d put myself in the shoes of the reader for every piece. What can they use after reading this? Not “what does this teach them”. What can they actually do differently on Monday morning? If the answer is nothing, the piece is incomplete. Even an essay should leave the reader with one specific shift they can make. Or, at least, leave them thinking.

And I’d skip the social media chase entirely. Just publish the work, share it once or twice in places where the right people might see it, and trust that real work compounds. The compounding is slow at first and then suddenly not. The audience I have now is real and it didn’t require me to perform.

The thing nobody says about your first 100 subscribers

You’re not building an audience. You’re doing your work and inviting people to watch it happen. Tattoo this in your brain 😄

The frame matters. “Building an audience” is performative — you’re trying to attract attention, which means you’re optimizing for what gets attention rather than what’s true. “Doing work and inviting people to watch” is the inverse. The work comes first. The audience is what happens when the work is good and visible.

This sounds like semantics. It isn’t. Every decision downstream of it is different.

If you’re building an audience, you write what’s likely to grow the audience. If you’re doing work and letting people watch, you write what’s true and useful, and you let the audience self-select. The first approach is faster in the short term and brittle. The second is slow and durable.

I had no idea I was doing the second one for years. I just had a project and I worked on it in public, in the open, for over a decade. The spec, the GitHub work, the conference talks, the documentation, the occasional newsletter issue. The community that resulted is the most valuable thing I’ve built, more valuable than the spec itself, more valuable than any of the jobs I had. It’s the only thing that compounded silently while I was doing the work.

Your first hundred subscribers don’t come from a tactic. They come from doing something real, in public, for long enough that someone notices.

The “long enough” part is where most people quit. They start a newsletter, post twelve times, get discouraged by the lack of growth, and stop. The ones who keep going past that point —even just a little past it— are the ones whose audience eventually shows up. And here’s the part that should be encouraging: the work doesn’t have to be in the newsletter. The newsletter can be one small surface where you occasionally talk about the work you’re already doing. The audience accumulates around the work, not around the newsletter.

The willingness to keep doing real work when nobody is watching yet is the only meaningful skill. Everything else is technique.

​P.S. I publish these on Commune, the open alternative to Substack I'm building. The discussion threads on each piece are where most of the interesting replies happen lately. If you want to read what other engineers are saying about this one: https://usecommune.com/n/franmendez​

No signup needed to read. If you want to comment, that takes about 30 seconds.