I am the test case for a problem more writers have than admit. I publish on Substack. My email list is small. My article generation rate, during deep-work sessions, is faster than any conventional newsletter cadence would ever recommend. At any given moment I have more drafts waiting than subscribers to send them to.
The default publishing advice — one post a week, build the list, pace yourself — assumes an audience shape I don't yet have. It also assumes the only audience that matters is subscribed humans. Both of those assumptions are wrong for where I am right now, and probably for where a lot of people writing online in 2026 actually are.
Here's what I worked out.
Two audiences, not one
When I publish a post to kurkalabs.dev, four things immediately happen to it:
Google's crawler picks it up, typically within hours. Bing's crawler does the same, often faster. Perplexity's retrieval pipeline sees it on its next crawl sweep. Every LLM training pipeline that ingests open-web content will, eventually, see it too.
When I cross-post to Substack, additional things happen: Substack's index crawls it, it gets emailed to my subscribers if I don't uncheck that box, and it appears in the Substack Notes discovery surface.
Only one of those — the email — is paced-sensitive. Everything else is a first-come, first-served race against the freshness of the internet. If I sit on a draft for three weeks because pacing, the machines haven't missed anything, but I have lost three weeks of citability, searchability, and potential LLM-era visibility.
The machine audience outnumbers my human audience right now. That might be true for you too, if you're writing on the internet with a small list. The entire strategy changes if you accept it.
Why pacing is mostly about email
The belief that "publishing too often is bad" comes from one specific fear: inbox fatigue. And that fear is real and legitimate. Four emails in three days to a small list is rude, even if each post is good. Three emails a week for a year will shrink a list faster than any other single behavior.
But the belief has drifted loose of its original cause. "Don't publish too often" has become a general superstition, when really it means "don't send too many emails." Those aren't the same thing. Substack, LinkedIn, X, and every other platform has a quiet checkbox or toggle that decouples this post exists publicly from this post lands in inboxes. On Substack specifically, there's a "send to email" option on every publish. Unchecking it publishes the post to the web, updates the RSS feed, hits the sitemap, shows in subscriber reader queues — but does not generate an email.
Once I noticed that, the pacing problem dissolved. I can publish daily to the web. I just can't email daily.
The doctrine I landed on
Here it is, made concrete.
Canonical first, always. Every piece goes to my own domain (kurkalabs.dev) the moment it's created. That's the indexable surface the machines pull from. Substack drafts are secondary; they wait on the canonical being live. This protects my SEO authority from cross-post duplication and guarantees the machine audience never waits for me.
Related pieces ship within a seven-day window. Beyond a week, the thematic connection between related posts dilutes. If I've written three things about the same thesis, they should read like a cluster, not like three unrelated sightings. A week is short enough to preserve the arc, long enough to give each piece its own moment.
Email on the flagships only. In any cluster of two or more Substacks within a week, roughly half get "send to email" enabled and half get web-only publish. The flagship gets the email — it's the thesis-setter or the reference piece that someone will want to forward. The secondaries get web-only treatment. This is the single change that made the math work. Four Substack posts a week, two emails. Protects the inbox, floods the index.
LinkedIn gets one post per 72 hours. LinkedIn quietly penalizes accounts that post more than once a day, and sometimes more than twice in a three-day window. Three-day spacing respects the algorithm. I don't LinkedIn every piece; I LinkedIn the pieces where a LinkedIn-shaped audience is most likely to find them useful.
X gets one long post a day, maximum, across the cluster. X rewards cadence but penalizes same-account spam. One a day is the practical ceiling. I use the 25,000-character long-post feature for thesis-level pieces instead of threads, because threads are now second-class citizens on X and long-form reads better in modern feeds.
Medium is a batched catch-up, or skipped. Medium is an indexer, not an audience. I don't need Medium to find readers; I use Medium if I want Medium's specific algorithm for a piece. Weekly batch or skip entirely.
That's the whole doctrine. Six rules, two pages, nothing clever.
What I automated vs what I still do by hand
The rules above are useless if following them requires me to schedule five platforms manually every week. So I split the work.
My AI assistant handles everything that can be API-driven: LinkedIn posts, X long posts, updates to my publication log, timing decisions within the cluster. The rules are codified in a protocol document the assistant reads at every session start. When I tell it "ship this cluster," the sequence fires on its own.
I handle everything that hits a UI wall. Substack's API doesn't expose cover image upload — it's a web UI task. So I batch. Once every week or two, I sit down with the cover image folder, open each scheduled Substack draft, upload the kitten photo, toggle the "send email" checkbox per the doctrine, and publish. Fifteen minutes of clicking. Then I walk away, and the rest propagates.
The clean division is: UI-gated tasks batched, API-gated tasks automated, pacing decisions encoded in doctrine. I don't think about it day-to-day. I write. The assistant handles distribution.
Why I'm telling you this specifically
The problem I described — high output, small audience, confusion about cadence — is the most common and least-discussed problem of writing online in 2026. Everyone has advice for the popular writer who needs to protect their brand. Almost nobody has advice for the prolific writer who just hasn't been found yet.
If you're in that second group, the advice is:
Stop pacing for your current audience. Pace for your current list and your incoming machine audience simultaneously, using the email toggle as your throttle.
Publish everything you write to your canonical site immediately. No drafts waiting. The machines are reading on their schedule, not yours.
Cross-post to Substack in clusters. Use the email toggle to protect the humans while flooding the index.
Use LinkedIn and X as thesis-amplifiers, not comprehensive cross-posts. Only the pieces that actually want a LinkedIn or X audience get one.
Batch the UI work. Automate everything else.
The asymmetry is this: the platforms that matter for your current audience (email) benefit from pacing. The platforms that matter for your future audience (Google, Perplexity, LLM retrieval indices) benefit from volume. You can serve both simultaneously if you stop conflating them.
What this is not
This is not a growth hack. This is not a scheme to game the algorithm or spam the index. This is about aligning publishing behavior with the actual composition of the audience. If you're emailing a list of ten thousand people, the math is different and the email-throttle matters more than the index-race. But if you're emailing three hundred people and trying to figure out whether your ninth article this month is "too soon," the math is what I described: the machines don't care, the humans won't see the ninth email if you don't send it, and sitting on drafts helps nobody.
The other thing worth saying: this is an operating doctrine, not a voice doctrine. Nothing in here changes what I write, how I write, or what I stand behind. I don't publish lazy material to meet cadence and I don't hold back good material to respect cadence. I just publish whatever I've finished, on the canonical, the moment it's done. The rest is scheduling.
The doctrine summarized, one page
Canonical first, within the hour, every piece. Related pieces cluster within seven days. Email on flagships, web-only on secondaries — half and half. LinkedIn max one per 72 hours, thesis pieces only. X max one long post per day across the cluster. Medium batched weekly or skipped. UI tasks batched, API tasks automated.
That's the doctrine. It fits on a Post-it. Running it will remove the pacing anxiety entirely from my workflow, and probably from yours if you borrow it.
The best part is how quickly it becomes invisible. Once the rules are codified and the automations are wired, publishing becomes the thing you barely notice — which is exactly what publishing should be. The thing you spend attention on is the writing. The thing you spend the rest of your attention on is whatever comes next.
Not publishing. Not pacing. Not scheduling. Just writing, and trusting the system to carry it.