A Weekly Posting System for a Team of One

Running an account alongside a real job fails in a predictable way: posting is treated as a daily decision, so it competes with work every day and loses most days. The fix is to make it a weekly decision that happens once.

By · · 6 min read

Drafted with AI assistance from our own research and Search Console data, and reviewed by Rahul A before publishing. Rules and prices change; check the linked official source before you act.

Why daily decisions lose

When "should I post today?" is asked every morning, it is asked at the worst possible moment — in the middle of whatever the day is actually about. It competes with urgent work and reliably loses, and losing does not feel like a decision, it feels like a busy day.

Moving the decision to once a week changes what is being decided. On Sunday the question is not "do I have time right now?" but "what is worth saying this week?", which is a different and much easier question. The output is a queue, and the queue removes the decision from the other six days entirely.

This is the whole idea. Everything below is mechanics.

The four parts

One capture file. A single place where anything that might become a post gets written down, unedited. A note app, a text file, a private channel — the tool does not matter, the singularity does. Two capture places means neither is trusted.

The rule that makes it work: no editing at capture time. "the thing about invoices that annoyed me" is a valid entry. A note that has to be well-formed before it can be written down will not be written down, and the capture file is the part of the system that everything else depends on.

One writing block. Ninety minutes, once a week, at a time that is actually protected. Turn four or five captured notes into three finished posts. Not a target of three good ones — write four and keep the weakest out of the queue.

Batching works because the expensive part of writing is not the writing, it is getting into the mode where writing is possible. Doing it once a week costs that transition once instead of three times.

One queueing pass. At the end of the same block, adapt each post for each network and put it in the queue with a time. This should take minutes, not an hour. If it takes an hour, the system will not survive, and the fix is the tooling rather than the discipline.

A two-minute delivery check, twice a week. Confirm that what was queued actually published. This is the step everyone skips and it is the one that catches the failure that costs the most — a post that never published and nobody noticed for a fortnight.

What the week actually looks like

  • Continuously, near-zero cost: notes into the capture file whenever something occurs to you.
  • Sunday evening, ninety minutes: read the capture file, pick four or five notes, write, adapt, queue.
  • Wednesday and Saturday, two minutes: check deliveries.

That is roughly two hours a week including the checks. It produces three posts and, most weeks, one spare that goes into the buffer.

The spare is the important part. Writing four and queueing three means the buffer grows by one post a week without any extra effort. After two months there is a fortnight of slack in the system, which is what makes a bad week survivable.

Protecting the block

The writing block is the only part that can fail, and it fails in two ways.

It gets moved. A block moved once gets moved again, and a block that moves twice is gone. Treat it as an appointment with the same status as a client call — and if it genuinely cannot happen this week, use the buffer rather than trying to squeeze it in somewhere worse.

It gets too big. Ninety minutes producing three posts is sustainable. The temptation after a good week is to extend it — six posts, four networks, a video. The next week's block then feels enormous, gets moved, and the system dies. Keep the block the same size and let the buffer absorb the extra ambition.

What to do when the capture file is thin

Some weeks nothing occurs to you. This is normal and it is not a reason to skip the block.

The capture file being empty usually means attention was elsewhere, not that nothing happened. A few prompts that reliably produce something from an ordinary week:

  • What did you have to explain to someone this week?
  • What did you get wrong, and what do you now think instead?
  • What question do you keep being asked?
  • What did you decide not to do, and why?

Each of these produces a post that is specific and could only have been written by you, which is the property that makes writing worth reading. Generic advice is what gets written when the capture file is empty and nobody asked these questions first.

When to stop doing this yourself

The system is designed for one person and it has a ceiling. Two signs you have reached it:

The block stops fitting. If ninety minutes reliably produces less than the cadence needs, the answer is a lower cadence or another person, not a longer block.

Adaptation becomes the bulk of the time. Writing three posts and adapting them for two networks is fine. Adapting for five or six is where the arithmetic turns, and the work stops being writing and becomes reformatting.

Neither is a failure. The point of the system is to be the smallest thing that keeps an account running while the actual work happens, and outgrowing it means the account is worth more attention than one person's Sunday evening.

Sources consulted: LinkedIn Help (linkedin.com/help) · Meta Business Help Centre (facebook.com/business/help) · YouTube Help (support.google.com/youtube)

Common questions

How much time does running a social account actually take?

For one person on two networks at three posts a week, budget about two hours: ninety minutes of batched writing and a few minutes of delivery checks. The number rises sharply with each additional network, because adaptation is per-network work, and with cadence, because writing does not batch indefinitely.

Should I write posts in advance or in the moment?

Write in advance as the default and post in the moment as the exception. A queue means the weeks when nothing happens are still covered, which is what an audience notices. Keeping the ability to post immediately matters for things that are genuinely time-sensitive, but most posts are not.

What if I miss my writing block?

Use the buffer and resume next week. That is exactly what the buffer is for, and letting it drain during a busy week is the system working rather than failing. If blocks are missed three weeks running, the problem is the cadence or the time slot, not discipline.

Is batching content bad for quality?

Usually the opposite. Writing under time pressure on the day of publication produces worse posts than writing several in a protected block, and batching creates the option to discard the weakest one. What batching does badly is reacting to something that happened this morning, which is why the ability to post immediately should be kept.

How do I know a scheduled post actually published?

Check it, and check that whatever you use reports each network separately rather than reporting the batch as one result. Tokens expire and networks reject posts without warning, so a post can sit in a queue marked as sent and never appear. Two minutes twice a week is enough to catch it while it still matters.

PostWharf is priced per workspace rather than per connected channel, and every plan carries unlimited channels. See per-brand pricing.