Most AI workflows aren't worth building.
That's not an engagement bait - it's just math. Building a workflow takes time. Maintaining it takes even more time. If it breaks when the model updates, you spend time on that too. For most tasks, the total cost of ownership exceeds what the workflow saves you.
But nobody tells you this before you build. The entire AI content economy is oriented around more: more templates, more automations, more scheduled tasks. “Steal this workflow” and “use my template” are common lead magnet patterns in info business.
But the question of whether a given workflow is actually worth the investment almost never comes up.
Here's the filter I use before I build anything.
1. Will I run this more than ten times?
One-off tasks don't deserve workflows. End of story.
If you're drafting a single landing page, just draft it. Use ChatGPT/Claude/Copilot/Whatever to help you. But you’ll build it only once. Maybe twice.
The time you'd spend building a repeatable system exceeds the time you'd save on a single use.
The “ten times” threshold is a rough heuristic, but it's a good start. Here is why:
…usually by run #4 you have all the “kinks” ironed out.
Below ten runs, the maintenance overhead eats the gains. Above ten, the math starts working.
The mistake most operators make: they build workflows for tasks they imagine they'll run repeatedly. Then the task changes, or the business shifts, or the workflow sits unused. Build for actual repetition, not aspirational repetition.
2. Is the quality compatible with automation?
Some outputs need judgment applied every time.
Your weekly newsletter, a client proposal, a key launch email - these live or die on nuance, and automating them produces generic output that you'll end up rewriting anyway.
Automation might actually create double work for you. First to build the automation, then to wrestle with its output.
Other outputs are fine at "good enough" …for ex: competitor research compilations, weekly metrics reports, first-draft blog outlines, or customer support email draft. These benefit from automation because they are either acceptable quality for internal use or rough draft before human passes judgement.
If the task requires a judgment IN THE PROCESS every time, don't automate it. If the task tolerates a solid baseline, automate it and refine.
The honest self-check: if the AI produces this at 70% quality, is 70% acceptable? If yes, build the workflow. If no, the workflow is lying to you about what it will deliver. Alternatively if the “last mile” just requests human’s quick look and minor fixes - it’s fine to automate as well.
3. Can I diagnose it when it breaks?
Nobody asks this question, because, founders and business owners try to get the system in as soon as possible.
But the second you start relying on a system you are at the mercy of that system.
Every workflow you build becomes infrastructure you're responsible for. When an API key expires, or a connector loses auth, or a model update changes behavior - you gotta be able to open the automation and fix it. With your “bare“ hands.
Could you?
If you built the workflow by following a tutorial you didn't fully understand, you can't diagnose it. You're now dependent on the tutorial's author, or on hiring someone to fix it, or on abandoning the workflow entirely.
Before you build, ask: do I understand every piece of this well enough to fix it at 2 am on a Tuesday? If the answer is no, either learn what you're missing before you build, or don't build it.
Three questions: ten-plus runs, quality-bar compatible, diagnosable when broken.
If a proposed workflow fails any one of them, reconsider building it.
Apply this filter to whatever you're about to automate this week. My guess is half of your ideas won't pass, and the half that does will be the ones worth your time.
Next week, I'll walk through the second filter - the specific cases where "good enough" is actually good enough, and where it quietly isn't.
~Michael
Kovis Logic helps operators build AI systems they actually understand. One post per week, Sundays.