What's taking more time than it should?

Built between paid acting gigs

What I built while waiting for the next call.

Acting comes with a lot of time between paid gigs. Enough time, as it turns out, to automate an entire content pipeline.

For Acting Myth Busters, every finished piece began as a long chain of separate jobs: finding a subject, checking what I had already covered, researching it, maintaining a backlog, preparing a script, blog post and caption, moving files between systems, preparing WordPress, scheduling the post, and sharing the finished work.

I used to handle those handoffs one by one. So I built a connected automation system in n8n to carry the repeated parts while keeping the publishing decisions with me.

That working system is what led me to help other small businesses look at the repetitive work in their own operations.

The working example

From topic signal to published post, with a person in the middle.

Five connected workflows carry the Acting Myth Busters process from topic discovery through posting and notification.

1. Find signals Check the backlog and gather bounded public topic signals.
2. Check prior coverage Compare possible subjects with work already published or waiting in the queue.
3. Prepare the content pack Assemble research, a script, a blog draft, a caption and the files needed for review.
4. Review and approve I choose the subject, review the material and decide when it is ready to move forward.
5. Publish and record Validate the approved content, prepare or publish the WordPress post, distribute the finished material and record what happened.

The system automates the repeated handoffs across the pipeline. It does not decide what deserves to be published.

Evidence from the system I use

I checked the system itself, not just a saved diagram.

Before showing this example, I checked the system behind Acting Myth Busters to make sure I wasn't describing an old plan. On October 4, 2026, all five workflows were turned on. Together, they contained 116 configured steps.

The records kept by the system also included successful runs for the workflows that create WordPress drafts, publish overdue scheduled posts, and share finished work on Facebook.

All five parts were active

Topic discovery, draft preparation, WordPress draft handling, the publishing safety net and Facebook distribution were all turned on when I checked.

Successful publishing activity was recorded

The system still held successful run records for WordPress draft creation, the publishing safety net and Facebook distribution. These are retained records, not lifetime totals.

Reported failures trigger an email

Each of the five workflows was connected to the same error handler, which emails me when a workflow reports a failure.

A critical tool gets its own check

A separate scheduled test checks a media-processing tool the pipeline depends on and emails me if that test fails.

Judgment stays with a person

Automation handles the handoffs. I choose what gets published.

I still:

• choose the subjects worth making;
• review the factual and creative material;
• decide when the work reaches an approved publishing state; and
• receive the notifications when work moves or a workflow reports a failure.

For another business, the approval point belongs wherever a person still needs to make the call. That may be before a report is sent, a customer record changes, a document leaves the business, or a public post goes live.

The unhappy path matters

A workflow also needs a plan for "nothing happened."

Useful automation has to handle empty results, invalid input, late posts and broken dependencies, not only the happy path.

The Acting Myth Busters system includes:

• backlog and no-result branches that stop unnecessary generation;
• content validation before a WordPress draft is created;
• a safety net that checks for overdue scheduled posts;
• a shared error route that sends an internal email; and
• a separate canary for a critical media-processing dependency.

Those controls reduce the chance that a failure stays quiet. They do not guarantee uninterrupted publishing or automatically repair every outside-service problem.

The transferable pattern

Where the same pattern may fit another business.

The useful pattern is broader than content: gather information, check it against rules or existing records, prepare the next piece of work, wait for approval where judgment matters, move it to the next system, and record what happened.

That pattern may fit:

• recurring reports assembled from several sources;
• onboarding steps that move between intake, documents, reminders and approval;
• document preparation and review queues;
• information copied between systems after a person confirms it; or
• follow-up tasks that need a clear owner and a recorded next step.

These are possible adaptations, not claims about paid-client deployments. The right first project is narrow, repeatable and easy to check.