Create, publish, distribute

Shipping day

A plan that never ships is a diary. Today item #1 leaves the building — made with AI doing the labour it is good at, you doing the part it cannot, and then the part almost everyone skips: distribution. The uncomfortable rule of content in 2026 is that creating the piece is at most half the job. A published asset nobody sees is not content marketing; it is filing.

The five-step workflow

Step 1 — dump your raw material. The data, the notes, the photos, the verdicts: the ore from Lessons 5.1 and 5.2. Everything, unpolished. If this step is empty, stop — you are about to generate slop, and the machine will not warn you.

Step 2 — AI-assisted structure and draft, from your material only. This is where the bare-prompt ban applies. "Write me a post about client onboarding" produces the same interchangeable output as everyone else's chatbot, because it starts from nothing. The legitimate prompt hands over your ore and asks for structure: here is my data and what I noticed; organise it, draft around it, add nothing I didn't give you.

Step 3 — the differentiation pass. You add what the machine could not know: the charts, the named example, the photograph, the verdict paragraph. This pass is where the piece stops being producible by a stranger — if you skip it, Lesson 5.1's test fails at the last step.

Step 4 — the human edit, for voice and truth. AI output is confidently wrong at a rate that should frighten anyone publishing under their own name. You are liable for every claim — legally, in the EU, and reputationally everywhere. Every number gets a source you can name; everything unsourced gets deleted, however good it sounds.

Step 5 — format natively for the channel, per your 5.3 adaptation notes, and publish on the planned date.

Storkflow ships the stall data

Watch the workflow run end to end. Lena is publishing her hero asset: "Where client intake actually stalls: data from 2,100 onboardings."

Step 1. A CSV export from the product database — 2,100 anonymised onboarding timelines — plus her voice-note observations from support calls.

Step 2. Her prompt, verbatim: "Here is a CSV of 2,100 anonymised client-onboarding timelines (columns: firm size, days to complete, waiting days per document type) and my notes. Structure a ~900-word article for accountancy practice owners. Lead with the most surprising finding. Use only the numbers in this file, exactly as given. Mark where a chart would help. Do not add any statistic, example or claim I have not provided." Ten minutes later she has a competent skeleton.

Step 3. She adds two charts (median days by document type; days waiting versus firm size), the consented Van Dijk anecdote from her Module 3 proof work — "We cut client intake from 3 weeks to 4 days" — and a verdict paragraph no neutral machine would write: the industry sells onboarding software as a checklist problem, and the data says it is a chasing problem.

Step 4. The edit catches a line the draft slipped in: "studies show automated onboarding reduces client churn by a third." Which studies? There are none — the machine invented a plausible sentence. Deleted. This is the step working as designed: the machine writes plausible; you are responsible for true.

Step 5. Formatted for the blog with a method note ("2,100 onboardings, last 12 months, firms with document tracking enabled, aggregated") and one CTA to the trial. Published on the planned date. Derivatives queued per the 5.3 map.

The law, briefly

Three rules, stated plainly because EU law states them plainly. Fabricating experiences or reviews is illegal, not merely tasteless — consumer-protection law does not care that a machine wrote them. Disclose AI involvement wherever a reasonable reader would otherwise feel deceived — an obviously AI-voiced video of "you", for instance; nobody needs a disclaimer that a draft was machine-structured. Never publish an AI-invented statistic — every number needs a source you can produce when challenged. Module 11 treats all of this properly; today you just don't break it.

Distribution is the other half

Here is the doctrine this module has been building toward: plan as much time to distribute a piece as you spent making it. The 50/50 rule. Distribution is not "pressing publish" — publishing is manufacturing; distribution is delivery. The standard actions, all free:

Send it to your list. Post the channel-native derivatives. Share it in one community where you genuinely participate — as a contribution, not a leaflet drop. Send it individually to three people who would actually care. Answer a real question somewhere with it, where it honestly answers the question.

Lena's log: the newsletter goes to the 900-subscriber list — its first send in months, and she opens by saying so. The four-post LinkedIn series starts. She sends the piece personally to three customers whose data patterns appear in it, including Maria van Dijk. And she posts it as an answer in an accountants' forum thread asking why client onboarding drags — the same forum her Module 2 desk research mined.

The result, reported honestly: 340 page views in week one, and 5 trial starts arriving through the piece's CTA. Small numbers. Also: against a baseline of 41 trials in a whole normal month, five from one asset — mostly because a 900-person owned list finally got marketed to. That is what "distribution is half the job" looks like in a real ledger.

Log where the first 50 views came from

One last habit, thirty seconds, quietly strategic. When the piece has its first response — fifty views, five replies, one comment — write down where they came from. That single observation, repeated per piece, is what re-weights next month's distribution: if the forum answer outperformed the LinkedIn series, next month knows. This is the feedback loop Module 10 will formalise; start feeding it now.

Ship it.

---