An honest retrospective on 114 technical posts in ten months: the compounding retrieval effect, the cadence that survived, and the traffic that never arrived.
I published my 114th post this month. The first one went up in October 2025, which makes it a little under ten months and an average of roughly two and a half posts a week — a number that sounds impressive right up until you look at what most of them actually did, which is nothing much.
I want to write the honest version of this retrospective, because the genre is full of dishonest ones. You know the shape: someone posts twice a week for a year, one article catches a wave, and the retrospective retroactively explains the wave as strategy. I don't have a wave. I have 114 posts, a handful that carry almost all the traffic, a long tail that gets read by maybe a dozen people a month, and a set of second-order effects that turned out to matter far more than the traffic ever did.
So this is what ten months of writing actually did — why I started (it wasn't ad revenue, and it wasn't audience), the compounding effect of having written things down, how writing exposes a shallow understanding faster than any code review I've sat in, the cadence I planned versus the one that survived contact with a real job, what I'd do differently, and what specifically did not happen.
The first reason was selfish and practical: I kept solving the same problems twice.
Six years of shipping production Flutter apps means I have solved offline sync, or a stubborn iOS build failure, or a Firestore query that needs a composite index, more times than I can count. And every time, I'd solve it from scratch — a fresh forty minutes of Stack Overflow, a fresh set of dead ends, a fresh moment of "I know I've done this before." My notes were scattered across Apple Notes, three Slack DMs to myself, and a scratch.md I lost in a repo cleanup. The knowledge existed and was completely unretrievable.
So the blog started as a knowledge diary. Not "content." A durable, searchable, public place to put the thing I just figured out, in enough detail that six-months-from-now me can execute from it without re-deriving anything. The public part isn't performance — it's a forcing function. Something I might publish gets written properly. Something in a scratch file gets written as // TODO: explain and stays that way forever.
The second reason was commercial but not in the way people assume. As a CTO who also takes on client work, I kept hitting the same conversation: a prospective client asks whether I can handle something — a real-time sync layer, a design system across dozens of apps, a performance budget on Flutter web — and I say yes, and they have no way to evaluate that yes. A portfolio shows you finished screens. It doesn't show you how someone thinks.
A blog is a credibility artefact in a way a portfolio isn't, because it shows working. When someone reads three thousand words on how you handle write conflicts in an offline-first app, they aren't evaluating your claim any more; they're evaluating your reasoning. That's a fundamentally different sales conversation, and it happens before you're in the room.
What was never on the list: ad revenue. There are no ads on the site. There is no newsletter funnel, no gated PDF, no "subscribe for my free course." The site runs on Firebase for $0 a month, which is a deliberate constraint I've written about elsewhere, and the economics of it are simple — it costs nothing to run, so it never needs to earn anything, so I never have to write a post I don't want to write.
Here is the thing that surprised me most: the blog changed how I work day to day, and the mechanism is boring.
I stopped re-solving problems. Not because I remember more — I don't — but because writing something down in publishable detail creates a retrievable artefact with my own reasoning in it. When a colleague asks how we should handle conflict resolution on a feature that goes offline, I don't reconstruct the argument. I send a link. When I hit the same Firestore index problem on a new project, the answer is on my own site, with the exact query and the exact index definition.
That sounds trivially obvious written down. It is not obvious in practice, because the value only appears after the archive gets big enough to have coverage. For the first thirty or forty posts there was almost no retrieval benefit — I'd write something and never touch it again. Somewhere around post sixty, the density crossed a threshold and the archive started answering questions I'd forgotten I'd answered.
The second-order version of this is better. Once you have coverage, posts stop being isolated and start being a graph.
I now write a post about a sync architecture and link out to my own earlier post on Firestore transactions instead of re-explaining optimistic concurrency for four paragraphs. That means the new post can go deeper rather than spending a third of its length on setup. Every link is a paragraph I don't have to write again, and a reader who wants the background can go get it.
The same effect shows up on the tooling side. My portfolio hosts 98 free browser tools and 32 browser games, all client-side, and every batch of them produced things worth writing down — a shared kit contract, a set of correctness bugs an adversarial review pass caught, a code-splitting strategy that took the main bundle down meaningfully. Those posts now do double duty: they document the codebase for me, and they're the most concrete demonstration of capability I have for anyone evaluating whether to hire me.
Write for retrieval, not for reach. A post that only ever helps you and six other people is still a post that saved you forty minutes the next three times you needed it. That's a return no engagement metric captures.
This is the effect I'd rank first if I had to keep only one.
I have sat in a lot of code reviews, on both sides. A good review catches bugs, unclear naming, missing edge cases, sometimes a structural problem. What a review almost never catches is that you don't actually understand the thing you built — because working code is extremely good cover. If it ships and the tests pass, nobody interrogates whether your mental model is correct or merely correlated with correct.
Writing has no such cover. The moment you have to explain why a mechanism works, in prose, to someone who can't see your screen, every gap becomes load-bearing and visible. I have started paragraphs I could not finish. Not because I couldn't find the words — because I discovered mid-sentence that I didn't know the answer.
A concrete example. I set out to write about idempotency in a sync outbox, confident I understood it, and got stuck on a sentence explaining why the client has to generate the key. I knew the practice. I had shipped the practice. But I couldn't articulate why a server-generated ID couldn't work, and that gap meant I couldn't reason about the failure mode properly. The answer — that the failure you're defending against is "the write succeeded and the acknowledgement got lost," which means the client must have the key before the first send — took me an hour of digging to state cleanly. That hour permanently upgraded how I design retry logic.
That's the trade. Writing a technical post costs you three to five hours and buys you an audit of your own understanding that nothing else in the job provides. Code review checks your code. Writing checks your model.
There's a smaller, sharper version of this: the act of writing a precise sentence forces precise thought. "You should probably use a transaction here" is a comment you can leave in a review. "The server accepts the write only if baseVersion == currentVersion, then bumps the version" is a sentence you either can or cannot write, and finding out which is the point.
I planned to publish every weekday. That is what everybody plans, and it lasted about eleven days.
What killed it wasn't motivation. It was that a real release week at work does not care about your content calendar. I had a shipping deadline, I published nothing for nine days, and then I did the thing everyone does — felt guilty, tried to "catch up," wrote three thin posts in two days, and published all three. Those three are among the worst posts on the site. They exist because a streak existed, which is the exact wrong reason for a post to exist.
The cadence that actually survived ten months is roughly two a week, with permission to be zero. Not a schedule — a floor and a release valve. In a good stretch I'll publish four or five because I've genuinely got that much to say. In a bad stretch it's one, or none, and nothing bad happens.
The reason two a week works and five a week doesn't isn't time. It's supply. A good technical post is downstream of having actually done something worth writing about. I can build things faster than I can write about them, but not five times a week, and when the writing outruns the doing you start reaching — which brings me to the mistake I made most often.
If I could rerun the ten months, I'd publish maybe 70 posts instead of 114, and the 70 would be the good ones made better.
The pattern is stark when I look at the archive. The posts that still get read, still get linked, still come up in client conversations, are the long ones — 2,500 to 3,000 words, one topic, taken all the way down to the operational details nobody else bothers to write. The ones nobody reads are the 900-word ones that explain a concept you could get from the official docs.
The uncomfortable maths: a 3,000-word post takes maybe three times as long as a 900-word post and delivers something like ten times the value, because depth is where the differentiation lives. Nobody needs another surface-level explanation of setState. The internet has infinite shallow content and a permanent shortage of people willing to write down the operational details. That's the gap, and I spent too much of the first six months not writing into it.
I sat on the failures for months, and they turned out to be the most useful posts I've written.
The instinct is understandable — you're building a credibility artefact, so you write about things that worked. But "here is the architecture I chose and why it's good" is a much weaker post than "here is the architecture I chose, here is where it broke in production, here is what I'd do differently." The second one is evidence you have actually run this in anger. The first one is indistinguishable from a well-read person summarising a blog post they liked.
The bug write-ups have been the clearest case. A post about a parity check that was inverted so every generated puzzle was mathematically unsolvable, or a layout error that silently rendered a whole screen blank in release mode while static analysis stayed clean — those get read, and they get read by people who have been bitten by something similar and want to know they aren't alone. Success stories are marketing. Failure stories are engineering.
This is the one I'm least proud of and it's worth naming plainly.
Somewhere in the middle stretch I wrote a handful of posts on topics I hadn't actually shipped — things that were adjacent to my work, things I'd read about, things that seemed like they'd do well. They read fine. They're also hollow, and I can tell exactly which ones they are because they have no specifics in them. No file names, no numbers, no "and then this broke."
Those posts didn't just underperform. They were worse than nothing, because the whole value proposition of the blog is that it's a record of things I've actually done. A post about something I haven't done dilutes the signal on every post about something I have. My rule now is simple: if I can't put a real number, a real file name or a real failure in it, I haven't earned the post yet.
Let me be specific about the disappointments, because this is the part retrospectives usually skip.
It is not a traffic firehose. Ten months and 114 posts did not produce an audience that shows up because I published. Most posts land, get a modest trickle from search over the following weeks, and settle into single or low-double-digit monthly reads. That's the median outcome, and it's the outcome for the large majority of the archive.
The distribution is brutally power-law. A handful of posts — fewer than ten — account for more than half of everything. They're all deep, all operational, all answering a specific question someone types into a search bar in a moment of pain. Nothing about them was predictable in advance; two of the ones I was proudest of did nothing, and one I nearly didn't publish became one of the top performers.
Nothing compounds on the schedule you want, either. SEO on a new domain is slow in a way that is genuinely demoralising for the first three or four months — you publish good work into what feels like a void. Most of what I published in the first two months only started getting traffic around month six. If you need feedback faster than that to stay motivated, you will quit at month three, and month three is roughly when it starts to work.
And it did not make me famous, or land me on a conference stage, or produce a flood of inbound. It produced some inbound, and better-qualified conversations, and that's a different and more useful thing.
If the traffic is modest and there's no revenue, what did 114 posts buy?
Clarity, first. I think more precisely about the things I've written about than the things I haven't. That is not a vague self-improvement claim — it shows up in design discussions, where I can state a trade-off cleanly instead of gesturing at it, and it shows up in code, where I reach for the right pattern faster because I once had to justify it in prose.
Optionality, second, and this is the one that surprised me. A public body of work is an asset that generates opportunities you didn't plan for and can't predict. Someone reads a post and starts a conversation. A recruiter opens with a technical question instead of a job description. A client arrives already convinced and the conversation starts at scope rather than at credentials. None of that is a funnel. It's a wider surface area for good things to hit.
A compounding personal archive, third, which is the thing I'd have valued most if I'd understood it at the start. In ten years the traffic numbers will be irrelevant and the archive will still be the most complete record of how I think about building software that exists anywhere.
That's the frame I'd offer anyone thinking about starting. Don't do it for traffic — the traffic is a lottery and mostly you lose. Do it because writing things down makes you better at the job, and because a public record of your thinking is quietly the highest-leverage career asset you can build in an hour a day, and because in the worst case where literally nobody reads it, you still get all of that.
Ten months and 114 posts did not make me an influencer, and I'm relieved about that. What it made me is a more precise engineer with a searchable record of six years of hard-won specifics and a set of conversations that start further along than they used to. If you're weighing whether it's worth the hours: the traffic probably isn't, the clarity absolutely is, and the optionality is the part you won't be able to see until you're a year in and something good arrives from a direction you never planned for.