TL;DR: Over September and October I wrote about the architecture decisions behind five small, mostly-free tools I've built — OpsFlow, Araç Sağlık Karnesi, Cerezmatik, LeadPilot, and FormJet. Same writer, same rough format, pretty different results. Here's what I noticed about which posts actually landed and why.
The format I stuck with
Every post followed the same shape on purpose: a specific technical decision, the simpler alternative I considered and rejected, the trade-off I accepted, and a code snippet that's actually from the thing I built rather than a generic example. No "10 tips" posts, no top-of-funnel "what is a webhook" explainers — just the decision itself, argued honestly, including the part where the decision has a real cost.
What I'd do again
Naming the alternative I didn't pick did more work than describing what I did pick. The Kafka-vs-Redis post and the FormJet schema post both got more engagement in the "why not the other thing" section than in the description of the actual implementation. People reading dev-focused platforms already assume you can build the thing; what they're actually curious about is the judgment call.
Admitting the trade-off explicitly, instead of only in a closing paragraph, changed how comments read. Posts where I stated the limitation as its own section — "the honest trade-off" — got fewer comments pointing out the limitation as if it were a flaw I'd missed, and more comments engaging with whether they'd have made the same call. That's a better conversation to be having.
What I'd change
Cross-posting identically to Medium and dev.to undersells both. Dev.to's audience wanted more code, faster; a couple of comments on Medium were clearly from a less technical reader who wanted more context on why the product exists before the architecture discussion started. Next round, I'd keep the technical spine of each post shared but write a different opening 2-3 paragraphs per platform.
A locally-specific post (KVKK, not GDPR) outperformed my expectations for a narrow topic. I almost skipped writing about Cerezmatik because "cookie consent" felt like a boring, saturated topic. The angle that made it work wasn't the tool, it was the specific mismatch (GDPR-shaped tools misapplied to a different legal regime) — that's a lesson I should apply more deliberately: the interesting post is rarely "I built X," it's "here's a mismatch nobody else pointed out."
The one number worth sharing
None of these five tools got meaningfully more signups from the writing directly — that was never really the mechanism I expected. What it did do consistently: gave me something concrete to link to instead of a bare GitHub repo when a potential user asked "how does this actually work," which is a much better answer than "trust me."
If you're building something small and solo and deciding whether writing about it is worth the time, my answer after six weeks is: not for the traffic, but for having a real answer ready the next time someone asks how it works.
Top comments (2)
The part about stating the trade-off as its own section, and getting fewer "you missed this flaw" comments, is useful. Did that change who commented too, or just what they said? I'm curious if the people who engaged were builders weighing the same call versus readers hunting for mistakes.
The last point matches what I've seen. Writing rarely drives signups by itself, but it gives you a page to send when someone is already half interested, and that's the moment it pays off.
One thing I'd add for small tools: pair the post with a concrete paid option. A fixed outcome, a clear input, a price. Then when someone reads the FormJet schema post and thinks "I want this set up for my form", they have something to say yes to instead of a repo. One paid request tells you more about demand than six weeks of view counts.
The KVKK example is the best lesson in the post. A narrow mismatch gives the reader a reason to stop scrolling.