Twelve posts in. I started this blog with a specific intention: to write seriously about how I think about building products, not as a content strategy exercise but as a discipline. To articulate the reasoning behind the decisions I make, to put opinions on the record, and to see what happened when the ideas met an audience.
What I did not expect was how much the writing would change the thinking. Articulating a process forces a clarity that thinking alone does not produce. When a decision has to survive a sentence, it either sharpens or it dissolves. Several things I thought I believed turned out to be habits I had not examined. Several things I had not thought to examine turned out to be the most interesting things I had to say.
This post is a reflection on what twelve posts have taught me: which arguments landed and why, what the act of writing publicly revealed about the work itself, and what I would do differently if I were starting again. It is not a metrics post. The numbers are early and the sample is small. It is a reflection on the discipline, what building in public actually costs and what it actually returns.
Articulating a process forces a clarity that thinking alone does not produce. When a decision has to survive a sentence, it either sharpens or it dissolves.
WHAT THE WRITING REVEALED ABOUT THE WORK
Opinions are more useful than observations
The posts that generated the most response were not the ones that described how to do something. They were the ones that took a position on why something matters or why a common approach is wrong.
My post on Why Side Projects Do Not Prove You Can Ship did not tell anyone something they did not already suspect. It named something they had felt but not articulated, which turns out to be more valuable than information. People share things that validate their experience, not things that merely inform it.
The post on The Hidden Cost of Skipping the Design Phase in Agile Teams generated the most internal sharing, the kind where someone sends it to their team rather than just reading it themselves. That happens when a post names a problem that an organisation has but has not diagnosed. The observation is not new. The precision of the diagnosis is what makes it shareable.
The lesson is that the most useful thing a technical blog can do is not teach. It is to give a reader language for something they already know to be true. Teaching scales poorly. Naming things scales indefinitely.
The posts I thought were niche reached the broadest audiences
I expected my post on Designing for Slow Connections to reach a narrow audience. Infrastructure-constrained markets, developers building for emerging economies, product teams with global ambitions. What I did not expect was how many developers in London, Berlin, and San Francisco recognised the problem from their own experience. A commuter on the Underground. A conference attendee on shared WiFi. The constraint is not geographic. The post found an audience I had not targeted because the problem was more universal than the framing suggested.
The same happened with the Integrating Payments in Complex Markets post. I wrote it for teams building in complex markets. The responses came from developers everywhere who had hit the same webhook reliability problems, the same reconciliation gaps, the same checkout flow complexity, regardless of geography. The specific market context gave the post credibility. The underlying problems gave it reach.
The implication for how I think about future posts: the most valuable angle is usually the one that starts from a specific, concrete experience and works outward to the universal principle, rather than starting from the universal and trying to make it concrete. Specificity earns trust. The universal is the reward for the reader who follows the argument.
Specificity earns trust. The universal principle is the reward for the reader who follows the argument to the end.
Writing about process reveals gaps in the process
The most unexpected benefit of writing the [LINK: From Figma to Deployed] post was discovering, mid-draft, that two phases I thought were distinct were actually entangled in a way I had not noticed while doing them. Writing the sequence forced me to think about why each phase precedes the next, and in doing so I found a dependency I had been managing implicitly without understanding why it mattered.
This happened on smaller scales throughout the series. The act of explaining a decision to an imagined reader is the act of interrogating it. Some decisions survived the interrogation stronger than before. Others revealed themselves as habits that had never been properly examined. Both outcomes are useful, but the second one is the one that actually improves the work rather than just documenting it.
The practical implication: writing about your process is not just a communication exercise. It is a thinking exercise that produces returns that stay with you after the post is published.
WHAT ACTUALLY MOVED THE NEEDLE
Consistency over quality
The instinct at the start was to make each post as good as possible before publishing. The tension was between publishing on schedule and publishing something that felt finished. What I learned is that finished is a moving target and the schedule is the discipline.
A post published at 90 percent of its potential on time is more valuable than a post held at 95 percent until the moment passes. The audience that finds post three is more likely to read post four if it arrives when expected. The compounding effect of consistency is not visible early. It becomes visible when a reader who found the blog recently reads backwards through the archive and finds twelve posts waiting for them rather than three.
The argument matters more than the format
Early in the series I spent significant time on formatting decisions: heading hierarchy, pull quote placement, how much white space between sections. These things matter at the margin. What matters more is whether the central argument of the post is sharp enough to survive being summarised in one sentence.
The posts that performed best were the ones where the argument could be stated in a single sentence and the entire post was the evidence for that sentence. The posts that underperformed were the ones where the argument was implied rather than stated, where the reader had to do work to find the claim the post was making.
The discipline I now apply before starting any post is to write the argument in one sentence first. Not the topic. The argument. If I cannot state it clearly before writing, the post will not be clear after writing.
Internal links compound slowly and then quickly
The first few posts had no internal links because there was nothing to link to. By the time the [LINK: From Figma to Deployed] post was written, four previous posts connected naturally to it. By this retrospective, almost every post in the archive links to at least two others.
The practical effect is that a reader who arrives at any post now has multiple paths deeper into the blog. A developer who finds the EF Core post through a search engine can follow links to the project structure post, the build process post, and eventually to the design posts. The blog is becoming a network rather than a list, and that structure is what turns a single visit into a reader.
The compounding happens slowly and is invisible until it is not. It is worth building the links deliberately from post one rather than retrofitting them later.
The posts that required the most honesty performed best
The Building a Design System Alone post worked because it did not pretend the process was clean. It named the mistakes specifically, explained why they were easy to make, and described what a more honest approach would have looked like. Readers trust posts that acknowledge difficulty more than posts that describe only the successful version of a process.
This is counterintuitive for a portfolio blog, where the instinct is to present the best version of everything. What the performance of these posts suggests is that the best version of a technical blog is not the one that makes everything look effortless. It is the one that makes the difficulty legible and the reasoning transparent. That is what builds trust with the readers who are evaluating whether to work with you.
WHAT I WOULD DO DIFFERENTLY
Start with the most provocative post
The [LINK: Why Side Projects Do Not Prove You Can Ship] post was the third post published. In retrospect it should have been the first. It generated more discussion and more sharing than anything before it, and that energy would have been more valuable at the beginning of the blog when the audience was smallest and the need to establish a voice was greatest. The first post set the tone correctly, but the third post set the stakes. Those two things should have happened in the opposite order.
Build the email list from post one
The blog has no email list. Every reader who found a post and did not bookmark it or follow a social account is gone. The compounding effect of consistent publishing means nothing to a reader who has no mechanism to be notified when the next post arrives.
An email list started at post one would have twelve posts worth of compounding by now. Started at post twelve, it starts from zero while the archive is already substantial. The best time to start it was before the first post. The second best time is now.
Write shorter social posts earlier
The social posts accompanying each piece were too long in the early weeks. The short versions that came later, the ones that made a single sharp point rather than summarising the argument, consistently outperformed the longer ones. The short version is not a summary. It is a different piece of writing that stands alone and makes the reader want the full argument.
That discipline should have been established from post one rather than discovered by iteration.
THE THING THAT CANNOT BE PLANNED
The most valuable thing that building in public produces is not traffic or leads or authority, though it produces all of those given enough time. It is the feedback loop between writing and thinking. The discipline of having to articulate your reasoning publicly, knowing that it will be read by people who will push back if it is wrong, sharpens the reasoning in ways that private thinking does not.
Twelve posts in, I think differently about the work than I did before I started writing about it. Not because the writing taught me something new, but because the writing forced me to examine things I had been doing without examining. Some of those things held up under examination. Some of them changed.
That is the return that compounds most quietly and most durably. And it is the one that cannot be planned for. It just happens, post by post, when you take the work seriously enough to put it in writing.
CLOSING THOUGHT
If you are a developer or designer who has been thinking about writing publicly about your work and has not started yet, the advice is simple: start before you feel ready. The posts you publish before you are ready are not wasted. They are the ones that teach you what ready actually means. And the gap between where you start and where you end up, measured in the clarity of your thinking rather than the size of your audience, is larger than you expect and faster than you think.