A high bar, not a schedule
I started a publication and built the brakes in first: a gate whose default answer is 'no', a cadence that waits for something worth saying, and a definition of success that ignores the subscriber count.
I run a point-of-view publication on operating AI-first. The part worth explaining isn't the writing — it's the gate in front of it: four tests a piece has to pass to earn a post, a rhythm set by having something to say rather than a calendar, and a measure of success that's about who can be sent a link, not how many people subscribed.
I started writing a publication about operating AI-first — under my own name, using the work I'm already doing as the evidence. Before I decided what would go in it, I decided what would keep things out. The machinery I left out is more of the design than the machinery I put in.
Most of what makes a newsletter grow is the part I wanted no version of: the hook, the subject-line optimisation, the cadence you keep whether or not you have anything to say, the standing ask to subscribe. Those work. They also produce the exact thing I don't want to be — another person narrating their AI journey into a feed. So the publication has brakes where most have an accelerator.
A gate whose default is no
A piece earns a post only by passing four tests, and they're deliberately all-or-nothing.
- Is there a principle? Something transferable that stands on its own without the project attached to it. "I built X" fails. "Here's the thing building X taught me, which holds elsewhere too" passes.
- Does it make a point? Reporting that something changed isn't enough — plenty of real work is just a shipped fix, and that belongs on the site, not in someone's inbox.
- Is it distinguishable from every other AI newsletter? If the framing could be swapped for "five ways AI will…" and nobody would notice, it doesn't run.
- Is it safe to show? Nothing private — no client, no personal data — ever crosses the line. This one has no override.
The honest outcome of a gate like that is that most things don't pass, and the default verdict is "this stays on the site." That's the point of it. A bar that lets most things through isn't a bar.
On a story, not a calendar
The publication doesn't have a posting schedule, and that's a choice rather than an oversight. It publishes when several pieces of real work add up to something worth a reader's time — roughly every week or two, but only because that's how often that actually happens, not because a calendar said so.
The tempting model is one-to-one: every update to the site becomes an email. It's the wrong model. It turns a publication into a notification service and trains the reader to ignore it. Lower frequency with a real point each time is worth more than a steady drip, to me and to whoever's reading.
The number I decided not to watch
The obvious measure of a newsletter is how many people subscribe to it. I'm deliberately not using it.
What this is for is substantiation — evidence of how I think that the right person can encounter, or be handed, at the right moment. That makes the useful questions narrow ones. Can I send a specific person a link that answers what they were wondering about how I work? Would someone who already trusts me find it worth forwarding? Those are pull measures, and they can be true at a small number that a growth dashboard would call a failure. Optimising for the big number would mean writing for an audience this doesn't need, in a voice that isn't mine.
Why a person still presses publish
None of this is automated, even though the drafting is. The system can assemble a post and check it against the voice and privacy rules, but it can't decide whether there's really a principle there, whether the point earns the interruption, or whether the framing is honest. Those are the judgements the whole thing exists to protect, so a person makes them and a person pastes the result. The publication is live, under my own name, and it runs on exactly these rules — which is the most direct evidence I can give that they're real ones.