I once inherited a "workflow" from a previous freelance client that involved four different apps just to get an invoice from draft to sent. A doc editor, a PDF exporter with three configuration screens, a file renamer script someone had written in 2019, and an automation tool gluing it all together with six triggers.
The whole thing broke the week I started, because one API key expired and nobody noticed for a month.
That's the trap with complicated workflows: they feel powerful right up until the moment they don't, and then you're debugging someone's automation instead of doing the actual work.
The hidden cost of "powerful" tools
Every extra tool in your stack isn't just an extra feature. It's an extra thing that can break, an extra login, an extra thing to explain to a new hire, and an extra dependency you didn't know you had until it goes down mid-deadline.
Developers know this pattern well from software architecture. It's the same reason a monolith with three well-understood services often outperforms a microservices setup with twelve, if the team doesn't actually need that complexity yet. More moving parts means more failure surface, even if each part is "better" on paper.
Simple workflow: Draft -> Export -> Send
Complicated workflow: Draft -> Format check -> Export tool A ->
Naming script -> Automation trigger -> Cloud sync -> Send
Six steps versus three. The six-step version might save you four seconds per file when everything works. It costs you forty-five minutes when one link in the chain quietly stops working and you don't find out until a client asks where their invoice is.
Complexity should be earned, not assumed
This isn't an argument against automation. It's an argument against automation you built before you actually needed it.
A good rule: don't automate a task until you've done it manually at least a dozen times and can describe the exact repeatable steps without thinking. If you can't describe it cleanly, automating it early just bakes your confusion into a script that's harder to fix later than the manual process ever was.
I've seen this go wrong in two directions:
Over-tooled solo freelancers who spend a weekend setting up a project management system with custom fields, automations, and integrations for a business with three active clients. The setup time alone eats more hours than the manual method would have cost in a year.
Under-tooled dev teams who keep doing something manually for eighteen months past the point where a fifteen-minute script would have paid for itself. Both are avoidable if you actually measure the task before deciding its complexity budget.
A quick framework for deciding
Before adding a tool or automation step to your workflow, ask three questions:
- How often does this task actually happen? Weekly, sure, maybe worth streamlining. Twice a year, probably not.
- What's the failure mode if this tool goes down or changes its API? If the answer is "I'm stuck," that's a real cost, not a hypothetical one.
- Could a simpler, boring tool do 90% of this job? Boring tools (a plain converter, a basic spreadsheet, a single-purpose app) tend to be more stable long-term than flashy all-in-one platforms, because they have less surface area to change underneath you. That third question is the one people skip most often, usually because the boring option doesn't feel like "using the right tool for the job." But stable and unglamorous beats fragile and impressive most weeks of the year.
Where this shows up in everyday file handling
A concrete example most people run into weekly: turning a document into a shareable, locked-format file before sending it out.
You could build a whole pipeline for this. Watch folder, trigger conversion, rename, upload, notify. That's genuinely useful if you're processing hundreds of files a day and the volume justifies the setup and maintenance.
For most of us, we're converting a handful of files a week, and the actual need is just: take this Word doc or image, turn it into a clean PDF, done. I usually just run it through PDF Converter directly rather than maintaining a script for something that takes ten seconds by hand. No API key to expire, nothing to break silently at 2 AM.
That's the whole point. The complicated version isn't wrong; it's just solving a problem you might not have yet.
Simple doesn't mean lazy
There's a version of this advice that gets misread as "don't bother automating anything, just do everything by hand." That's not it either.
Simple means matching the tool to the actual scale and frequency of the problem, not the scale you imagine you might have someday. A single-purpose tool that does one thing reliably will usually outlast a complex stack that does everything, because the complex stack has more ways to quietly stop working while you're not watching.
Next time you're about to add a new tool, a new integration, or a new automated step to how you get work done, it's worth pausing on that third question: could something simpler and more boring get you 90% of the way there? Usually, it can.
If you're just trying to get a document into a clean, shareable PDF without setting up a whole pipeline for it, PDF Converter works fine for the occasional file and doesn't ask you to configure anything first.
Top comments (0)