The Make automation that was slower than manual

The automation that looked perfect on paper

I built a Make scenario to cross-post every new Ghost article to Dev.to. The idea was simple: publish once, appear twice.

The module listened for a new Ghost publish, grabbed the canonical URL, rewrote the excerpt into Dev.to's preferred format, then POSTed everything to the Dev.to API with a canonical link back to richardlemon.com.

On paper, it solved a boring problem: copying content into another box. In practice, it created problems that were worse than the original.

When the API keeps moving

The first leak in the system was the Dev.to API itself. Their accepted markdown flavor changed twice in three months, just enough to break things in annoying ways.

Each time the API shifted, the Make module started producing bad posts with broken heading levels or stripped code blocks.

Fixing it meant inspecting the JSON payload, updating the Make module, and republishing three failed posts. That debugging session took about two hours, for a platform that drove less than 2% of my traffic.

The problem was not that automation is fragile. The problem was that I had automated something where the upside was tiny. A small change upstream meant a long tail of downstream fixes for a channel that barely moved the needle.

The canonical URL that kept lying

The second leak was the canonical URL logic. The Make scenario captured the URL from Ghost as soon as the publish trigger fired, then passed it to Dev.to as the canonical link.

That sounds fine until you remember how publishing actually happens. I often tweak the Ghost slug in the final review: tighten the wording, remove a filler word, make the URL match the final title.

I wrote about this earlier in Make.com + Ghost: Auto‑Archiving Blog Posts With 0 Traffic.

Every time I did that, the automation quietly went wrong. The Make module had already captured the old URL, so Dev.to published a post pointing to a 404.

My choices were:

• Stop adjusting slugs, or
• Manually check and fix the canonical link on every Dev.to post

I picked the second option, which meant the cross-post automation required the same manual step as not having it at all. I was still opening Dev.to, still editing the post, still touching the URL. The only difference was that now I was cleaning up after a system that pretended to help.

Scheduling: when instant is actually wrong

The final straw was timing. Ghost and Dev.to do not have the same audience peaks. Publishing at a good time for one is not automatically good for the other.

The Make scenario did not care. As soon as I hit publish on Ghost, it fired the Dev.to post. That often meant my Dev.to posts went live at 2 AM CET.

To fix this, I ended up doing the thing the automation was supposed to avoid: opening Dev.to, copying my own text across, and scheduling the post for a better time.

At that point, the Make module was just a bad first draft. I would let it post, then go into Dev.to and:

• Fix the canonical link if the slug had changed
• Check the formatting if the API had twitched
• Adjust the publish time so it did not land in the middle of the night

That is not automation. That is assisted manual work, with extra steps.

More on this in my article A publishing system is not a writing system.

Security and clutter are still costs

There was one more problem that was less visible but still real: the scenario itself had a footprint.

Deleting it freed up a Make scenario slot, which was nice, but more important was the API key. The Dev.to key lived inside the scenario and in the exported Make blueprint as plain text.

That meant every backup of the scenario carried an exposed key, and every time I shared or stored that blueprint, I had another place to remember to scrub.

For something that barely affected traffic, I now had to think about key rotation, export hygiene, and whether an old file contained credentials I had forgotten about.

What the manual workflow actually looks like

After deleting the scenario, I moved to a fully manual process:

• Once a week, I batch cross-post recent articles to Dev.to
• The whole batch takes about 15 minutes
• I set timing based on when Dev.to is actually active
• I paste the correct canonical URL after the slug is final

No broken links, no surprise markdown changes, no hidden API keys in blueprints. The time cost is small and predictable. The quality is higher because I am present when the post goes live on that platform.

Read also Why my posts now start with five bullets.

The original Make automation was solving a problem that did not exist. The pain of cross-posting was never the clicking. It was the writing.

When automation is not the upgrade

The Dev.to scenario is a reminder that can be automated is not the same as should be automated.

Some rough checks that would have caught this earlier:

• Fragility vs benefit: If an upstream API changes often and the downstream benefit is under 2% of traffic, expect the maintenance to dominate.
• Human habits: If your normal workflow includes last-minute edits like slugs, any automation that assumes stability at publish time is going to lie to someone.
• Timing: If distribution channels have different peak times, publish everywhere instantly is probably wrong for at least one of them.
• Security surface: Every extra API key wired into an automation is another thing to rotate, hide, and remember.

In this case, deleting the Make scenario was the upgrade. Manual, boring, and fast turned out to be better than clever, fragile, and slow.