What 35 technical articles taught us about what developers actually read

While building Storyie — a Next.js + Expo diary app — we published 35 technical articles on Zenn over roughly six weeks. Writing nearly every day, we accumulated real data on what drives likes (❤️) and bookmarks (🔖), and what quietly disappears into the feed.

This post is not writing advice. It is an analysis of what actually happened across 35 posts, with the specific numbers to back it up.

TL;DR

What we built and wrote about

Storyie is a pnpm monorepo: Next.js on the web, Expo on mobile, SST on AWS, Supabase for the database, Stripe for payments. All 35 articles came directly from what we were building — no research posts, no opinion pieces unconnected to working code.

The articles broke down roughly into:

• Infrastructure and deployment — SST, Terraform, AWS, CI/CD
• Authentication and security — Supabase Auth, RLS, RBAC
• Architecture decisions — monorepo design, multi-tenancy, permission systems
• Cross-platform — sharing code between Expo and Next.js
• AI and automation — Claude Code, bot diary generation
• Solo dev operations — cost breakdowns, zero-ops infrastructure design

Pattern 1: design decision posts outperform implementation guides

The clear #1 by bookmarks was our multi-tenant feature gate post — 2 ❤️ and 4 🔖 on the day it published. Nothing else came close.

The hook was the contrast: why would a solo developer bother with multi-tenant design? The article answered that by walking through the actual decision — what we considered, what we rejected, and why the eventual design fit our specific constraints. Readers were not just getting a how-to; they were getting a window into a reasoning process they could evaluate against their own situation.

The rule we extracted: "how" gets you readers; "why" gets you bookmarks. Developers save posts they expect to return to when they face a similar decision. A recipe is disposable once you have followed it. A reasoning framework stays useful.

Pattern 2: real numbers generate immediate reactions

The two articles that reached 3 ❤️ fastest were both about concrete numbers:

• Solo dev cost breakdown — what we actually pay for AWS, Supabase, and Cloudflare per month
• Solo dev infrastructure design — decisions we made to avoid ongoing operations work

The cost article received 2 likes on the day it published. Developers genuinely want to know what things cost in production. Official documentation tells you what features exist; it almost never tells you what a real production workload runs per month. When you publish actual figures, you are filling a gap that no official source fills.

The zero-ops infrastructure post worked for the same reason from a different angle: developers want to know how solo builders handle production reliability without dedicated SREs. The answer, with specific decisions called out, is more useful than a general principle.

Pattern 3: infrastructure and architecture posts earn bookmarks

Looking at every post that received at least one bookmark:

Seven of nine bookmarked posts are infrastructure, architecture, or security. That is not a coincidence — these are the categories where developers return to a post mid-implementation to double-check a step or re-read a tradeoff. A deployment guide or RLS policy post functions as a reference, not just a read.

The outliers — Lexical editor and Expo-specific posts — are technically interesting but serve a smaller audience, and that audience was not actively bookmarking them.

Pattern 4: AI content gets likes, not bookmarks

Our AI bot diary generation post reached 2 ❤️ early and held near the top of all articles by likes. Bookmarks: zero.

The pattern is consistent with the function of each metric. A like is "this was interesting to read." A bookmark is "I want to come back to this when I am building something." AI workflow posts tend to describe a specific setup that worked for us — which is engaging but hard to transfer directly. The implementation details are tied to our codebase, our Claude setup, our specific prompts. Readers cannot easily copy it, so they do not save it.

There may also be a shelf-life problem. AI tooling moves fast. A post about Claude Code workflows written in early 2026 may not reflect what the tool looks like six months later. Bookmarking something you expect to become stale quickly is not rational.

Pattern 5: first-day engagement predicts everything

Across 35 articles, the pattern was consistent enough that we now treat it as a working rule:

• Posts that received a reaction within the first two days continued to accumulate engagement over time
• Posts with no reaction after three days almost never recovered
• Exception: our Supabase RLS multi-tenant isolation post received a like and bookmark on day 6, almost certainly from search traffic finding it later

The practical implication: if an article gets no traction in the first few days, it is more productive to revise and potentially republish than to wait. The Zenn feed algorithm amplifies early engagement; a post that starts cold has no mechanism to warm up on its own.

What did not work

Three categories consistently underperformed:

Lexical editor deep-dives. The articles were technically detailed and represented real implementation work. But the Lexical developer community is small, and most readers who encounter a Lexical post are evaluating whether to adopt the library — not looking for advanced implementation patterns. We wrote for the second group; the first group found us.

Terraform × Stripe. These are both niche enough individually. Combined, the audience is extremely small. The article was accurate and useful but reached almost no one.

Tool walkthrough articles. The Claude Code Action introduction post described the feature without adding much of our own judgment or context. Readers can find the official docs; what they cannot find there is an informed practitioner's take on when it is worth using and when it is not. We did not provide that.

The common thread: audience size is a harder constraint than writing quality. A well-written post on a topic with 50 potential readers will not outperform a mediocre post on a topic with 5,000.

What we would do differently

Lead with the decision, not the implementation

Most technical posts are structured as: background → implementation steps → result. The structure that worked better for us: here is the decision we made and why → here is the alternative we considered → here is what our implementation looks like as a result. The "why" section belongs at the front, not in a retrospective at the end.

Publish in series, not in isolation

Our multi-tenant design post funneled readers into the related RBAC and RLS posts. The series structure meant each article had a warm audience from the previous one, and the cluster of related posts built topical credibility that a single standalone article cannot. For any topic that naturally splits into related subtopics — and most engineering topics do — publishing as a series is strictly better than publishing as one large post or as disconnected individual posts.

Pair "solo dev ×" with specific technology choices

"Solo dev × cost" and "solo dev × infrastructure" both outperformed their equivalent posts without the solo dev framing. The large-company engineering blog already covers the technology; it almost never covers what those decisions look like at solo-dev scale. That gap is where individual developers writing about their own projects have a genuine advantage over corporate engineering blogs.

Volume as a strategy, but not as an end in itself

At 35 posts in six weeks, the hit rate was low by any measure: two posts with 3+ likes, one post with 4 bookmarks. But the volume strategy had a purpose beyond the individual posts — it established a regular publishing cadence, created a body of work that search can index over time, and generated enough data to actually learn from. A single carefully crafted post would have been better written but would have taught us far less about what to write next.

Key takeaways

Writing technical content as a solo developer is genuinely different from corporate engineering blogging. The advantages: speed, authenticity, willingness to share actual numbers and honest tradeoffs. The constraint: smaller audience than a recognizable company brand.

What the data says to focus on:

1. Write about decisions, not just implementations. The "why" drives bookmarks; the "how" drives one-time reads.
2. Publish real numbers. Cost, scale, time — concrete figures fill a gap that documentation never fills.
3. Favor infrastructure, architecture, and security topics when you want posts that stay useful over time.
4. Expect AI and tooling posts to be low-durability. They get read and forgotten; they rarely become reference material.
5. Watch first-day engagement. If a post does not land in 72 hours, revise and republish rather than wait.

Related Posts

• Building a Monorepo with pnpm and TypeScript — the workspace setup that underpins all the infrastructure articles referenced here
• Cross-platform Lexical with use dom: monorepo gains and the bridges you still own — the Lexical deep-dive that confirmed the niche-topic ceiling firsthand

Try Storyie

Storyie is the app all 35 of these articles came from. If you want to see what the cross-platform editor, multi-tenant design, and zero-ops infrastructure look like as a product, write a diary at storyie.com or on the iOS app.