How to Run a Weekly Publishing Workflow Without Burning Out

Publishing weekly is not a writing problem. It is a queueing problem, and it is usually solved badly — by writing harder in the days before the deadline, which works until the first week something goes wrong.

What follows is the workflow we would build for that cadence: a pipeline rather than a sprint. It is deliberately unglamorous, it adds latency, and it is the reason a schedule survives a bad week.

The five stages

1. Idea. A one-line claim and who it is for. Nothing else.
2. Research and testing. Actually using the tools, recording what happened.
3. Structure. Headings and the claim under each one. No prose yet.
4. Draft. The writing.
5. Edit and publish. Claims check, links, metadata, images.

One rule governs the whole thing: nothing moves to the next stage on the day it arrived in the current one. A day of distance is the cheapest quality control available.

Checkpoint one: structure review

Before anyone writes a sentence of prose, a second reader goes through the heading structure and the one-line claim sitting under each heading. Not the prose — there is no prose yet, and that is the point.

This catches, in order of frequency:

• An article with no actual claim — a topic pretending to be an argument
• Sections in an order that requires the reader to hold something in mind for three headings
• A claim nobody actually tested, which nobody notices once it is wrapped in fluent prose

Fixing structure costs twenty minutes before drafting and half a day after. This checkpoint pays for the whole process on its own.

Checkpoint two: claims review

Before publishing, someone goes through the draft and marks every factual claim. For each one: where did this come from?

Three outcomes:

1. First-hand: someone here did this and recorded what happened. Fine — and note the date, because software changes underneath published claims faster than anyone expects.
2. Sourced: a document, changelog or report says it. Fine, provided the source is linked and actually says the thing being claimed. Check the second half; a surprising share of citation failures are a real source that does not support the sentence attached to it.
3. Neither: it sounds right. Cut it, verify it, or attribute it as a vendor claim. This is where nearly everything that would later have needed a correction gets caught, and it is worth being ruthless — fluent prose disguises unsupported claims extremely well.

The buffer

Keep two finished pieces in reserve at all times. This single practice is the difference between a weekly cadence and a weekly panic, and it is the first thing to build before committing to a schedule publicly.

Without a buffer, every deadline creates pressure to publish whatever is closest to done. With one, "this is not ready" costs nothing — which is the only condition under which anyone actually says it. A schedule with no buffer does not fail loudly; it degrades quietly, one slightly-thin piece at a time, until the cadence is being met and nothing being published is any good.

Building the buffer is the hard part, because it means writing three pieces before publishing the first. Do it during the period before anyone is watching, not after you have announced a schedule.

What the week looks like

Day	What happens
Monday	Publish. Structure review for next week's piece.
Tuesday–Wednesday	Drafting. Testing for the piece after.
Thursday	Claims review on the draft.
Friday	Edit, images, metadata. Into the buffer.

Note that the piece being published on Monday was finished the previous Friday, and the piece being drafted this week publishes the week after. The pipeline is roughly three weeks deep from idea to publication — that latency is the cost of the cadence, and it is worth it.

Where it does not work

Anything time-sensitive. A three-week pipeline cannot respond to something that happened yesterday, and no amount of tuning changes that — the latency is the mechanism, not a defect in it.

The workable response is not to compete there. A publication built around breaking news needs a much shorter pipeline and correspondingly lighter checkpoints; trying to run both cadences through one workflow produces something too slow for news and too rushed for everything else. Decide which one you are, and let the other go.

Adapting it for one person

The workflow survives being run solo with a single substitution: wherever it says "a second reader", substitute a day of distance. Reading your own heading structure the next morning catches a surprising share of what a colleague would catch, because the failure being hunted — a topic pretending to be an argument — is invisible while the idea is still in your head and obvious once it is not.

What does not survive being solo is quietly dropping the checkpoints. They are the entire value of the process. The five stages are just scaffolding to hang them on. Protecting the time for them is a separate problem, and two blocks a day is usually enough.