I built a content system whose main job is to say no

I spend a lot of my working life telling founders they may not need to build yet. Then I spent most of last year not posting on LinkedIn, which is uncomfortable to admit for someone whose whole positioning is about honesty before spend.

The interesting part is why. It wasn’t that writing a post takes too long. A post takes twenty minutes. It was that when I sat down to write one I had nothing specific to say. I had opinions, and opinions are cheap. What I lacked was the thing that makes a post worth reading: a real situation, with a real decision in it, recent enough that I remembered the details.

That is a sourcing problem, not a writing problem. Almost every content system I looked at solves the writing problem. So I built one that solves sourcing instead, entirely inside a Claude chat window. No code, no automation platform, no scripts on a server. Partly because it was fastest, partly to find out whether a real recurring workflow could run that way. It can.

The problem to solve

I sit in something like twenty to thirty calls a week. Discovery sessions, sprint reviews, awkward conversations where someone shows me a prototype they paid for and I have to tell them what it actually is. Every one contains something I would happily argue in public. And every one was evaporating, because the argument was buried in fifty minutes of transcript and I never went back.

So the requirement was never “write me posts.” I needed somewhere to store the interesting points as they happened, help turning them into stories, those drafted and scheduled against a calendar with rules about pace, and then actually posted without me hand-carrying each one.

That breaks into five steps, each built as a separate instruction set doing exactly one job:

1. Find the topics. Read every meeting, daily, and spot what carries an argument.
2. Triage the topics. Decide which are ready to write and which need me first.
3. Run the interview. Turn the half-formed ones into real stories, in my words.
4. Draft and sequence. Write the posts, make the images, place them on the calendar.
5. Post them. Schedule in LinkedIn, verify, and record it.

Breaking it up like that is the base the whole system rests on, and the one place my engineering background probably showed. But it isn’t rocket science. All it amounts to is asking what happens first, what that produces, and what the next thing needs to start. That is logical thinking, not engineering. If you can describe your own process to a junior employee in order, you can build an automated workflow.

Step one: find the topics

The first step reads the meetings. It runs daily, works through every recorded call since the last run, and asks one question of each: is there anything here that would make a post. Not “summarise this call.” Not “extract insights,” a phrase that should make anyone suspicious. Just: did somebody say something that carries an argument. Anything qualifying goes into a topic list with its source.

One detail matters more than the step itself: merging. If the same situation comes up in four calls across three weeks, it does not create four ideas. All four sightings attach to one row, so the idea gets richer instead of the list getting longer. The first version didn’t, and within two weeks I had eleven variations on one thought.

Step two: triage the topics

Step one just fills a list. Content ideas are not a scarce resource. Anyone can generate a hundred in an afternoon and none will be any good.

The step that made the difference sorts every live idea into two piles: things I have enough real detail to write, and things that only look like posts because they sound like posts.

The second pile is the whole point. An idea there is not deleted and not drafted. It waits until I get interviewed about it properly. A lot of what comes out of a meeting is a half-thought: the shape of an argument with none of the specifics. Hand that to a language model and ask for a post, and you get one, and it is confidently written, and it says nothing, and everyone can tell.

The rule I gave this step is the one I would give a junior developer: never invent a fact to make something draftable. If the detail that makes the story land is not there, the story is not ready. Go and ask.

I expected drafting to be the load-bearing part. In practice it is the easy bit, and the discipline of refusing to draft is what keeps the output from becoming the sludge that fills most of my feed.

Step three: run the interview

The ideas needing input go into a session where I get asked questions. Before it asks anything it reads the strategy, the previous sessions, and the topics step two flagged as needing filling in, so the questions aim at whichever of my five content pillars is running thin. Four posts about AI prototypes and nothing about running the company, and it comes after the company material.

The whole interview runs as questions put to me one at a time, and I answer by talking at my laptop as if a journalist were sitting across the desk. That part matters more than it sounds. I am allowed to ramble. I go off on the tangent, double back, correct myself, add the bit of context that only makes sense once you know the other thing. Typing that out would take an hour and I would tidy it into something flatter as I went. Speaking it takes a few minutes and what comes out is already in my voice, because it literally is my voice.

This step never writes a post. It only gathers. Keeping the two jobs separate was deliberate: when one process both interviews and drafts, it steers questions toward the post it has already decided to write. Split, the interview is allowed to end with “there is nothing here.”

The output is a story bank. Real situations, in my words, specifics intact. That is the actual asset. Everything else is scaffolding.

Step four: draft and sequence

Drafting pulls from the story bank, produces the posts, generates the brand card images, and sequences them across varied days and times.

One decision here has saved me the most grief: the voice rules, the pillars and the publishing rules live in a document read fresh on every run. They are not baked into the process. When I decided posts must close on a contestable line rather than a summary, I changed one sentence in one place and every future draft obeyed it. Same when I told it to never, ever, ever use an em dash.

The publishing rules are mostly limits. Never schedule more than eight weeks out. Never more than three substance posts a week. Never post pricing. Never post anything against a client, current or former. Every post carries an argument or a decision, not a summary.

The eight week limit came from getting it wrong. I filled the calendar three months deep, it felt tremendously productive, then a client situation changed and half of it was no longer true. A content calendar that far out is not a plan, it is a commitment to opinions you have not formed yet.

Nothing here publishes. Everything lands as a draft in a schedule I read through, edit and approve, or don’t.

Step five: post them

When I approve something, the final step schedules it in LinkedIn at the recorded time and attaches the card. It only touches what I have explicitly approved, never edits approved copy, and never treats one approval as permission for a batch.

And it marks nothing done until the post is visibly sitting in LinkedIn’s scheduled list. Not when a spinner finishes. Not when a counter goes up. Verified, or not done. That sounds excessive until the first time a UI reports success and nothing was scheduled.

I will be straight about the part still broken: attaching the card image reliably runs into four separate technical walls, so some runs need me by hand. I know the fix and haven’t built it, which is its own kind of honesty about priorities.

What I would take from it

None of the pieces are clever. What made it work was deciding the bottleneck was sourcing rather than writing, then structuring everything around a step whose only job is to say “not yet, go and find out more.”

Which is, I notice, what I get paid to say to founders about their products. The constraint is usually the same: the problem is almost never that you cannot produce the thing. It is that you have not yet earned the right to.

If your content system has no step that is allowed to produce nothing, it is not a system. It is a machine for filling a feed, and the feed already has plenty.