I've seen teams spend weeks building automation that breaks in production on day three. I've watched "quick wins" turn into six-month maintenance nightmares. And I've done it myself—chasing the automation dream without asking the hard questions first.
Here's the checklist I run through before touching any automation code. It's not sexy. It won't impress anyone at a conference. But it'll save you from the mess I've cleaned up too many times.
—
What Problem Are You Actually Solving?
Write this down before you write any code. Not "automate the deployment" or "reduce manual work"—what's the actual pain? Is the manual process taking 45 minutes every time? Is it error-prone because Dave left and nobody knows what he did?
Be specific. "Our weekly server provisioning takes 4 hours of manual clicking through the AWS console and fails 30% of the time because someone misses the security group step" is a real problem. "We need more efficiency" is not.
If you can't explain the pain in one sentence, you're not ready to automate. You'll build something that works but nobody uses, or worse, something that solves the wrong problem.
—
Can You Measure It First?
Before you automate, measure the manual process. I don't mean a vague "it's slow." I mean actual numbers: how long does it take, how often does it break, what's the recovery time when it does.
I once worked with a team that wanted to automate their backup verification. When I asked them to show me the current process, it turned out they weren't actually verifying backups at all—they just assumed they were working. The "problem" was imaginary. They needed monitoring first, not automation.
If you can't measure it, you can't improve it. And you definitely can't prove the automation helped.
—
Does the Manual Process Even Work?
This one seems obvious, but I've seen teams automate broken processes all the time. They build a beautiful Terraform template for infrastructure that was never properly designed in the first place. Or they script a deployment process that has never been documented and nobody can actually do manually anymore.
Run the manual process yourself. Document every step. Find the edge cases. If you can't perform the task manually, reliably, you have no business automating it.
The automation will inherit every flaw in the manual process—and amplify them.
—
What's Your Rollback Plan?
Your automation will break. Not if, when. The question is whether you can recover quickly or spend the weekend fixing production.
Before you deploy anything automated, know exactly how to undo it. Can you tear down the infrastructure? Revert the database changes? Restore from the backup you should have made first?
I've seen automation that works perfectly in testing destroy production because nobody thought about what happens when it fails halfway through. The script doesn't know it failed. It just keeps going, or it fails silently, or it leaves your system in a half-configured state that takes hours to debug.
Build the rollback before you build the automation. Test the rollback. Then test the automation again.
—
Who Maintains This in Six Months?
This is where most automation dies. The original author moves to another team, leaves the company, or just forgets. The documentation was "in their head." The next person touches it and has no idea what any of it does.
Assign ownership. Document what the automation does, what it depends on, what breaks it, and how to fix it. Not a wiki page nobody reads—a README in the repo, a runbook, something that answers the questions people will have at 2 AM.
And be honest about maintenance burden. Every automation piece is something else that can break, something else to update when dependencies change, something else that needs security patches. I've seen teams add "simple automation" that becomes a full-time job nobody signed up for.
—
What Are You Not Automating?
This seems backwards, but it's important. Every automation choice is a trade-off. When you automate one process, you're spending time and attention that could go elsewhere. You're adding complexity to your system.
Sometimes the right answer is to delete the process entirely. If nobody actually needs that weekly report, don't automate its generation—just stop doing it. I've seen more time wasted maintaining automated reports that nobody reads than almost anything else.
Before you automate, ask: should this exist at all?
—
What I Would Do First
If you're looking at a new automation project, here's where I'd start:
- Measure the manual process. Time it. Count the failures. Get real numbers.
- Run it manually while documenting every step. If you can't document it, you can't automate it.
- Build the smallest possible version. Don't try to automate everything at once. Automate one piece, test it, verify it works, then expand.
- Add monitoring before deployment. You need to know when it breaks, not when someone complains.
- Write the rollback first. Then test it. Then test it again.
- Assign a human owner. Not a team, not a rotation—a specific person accountable for knowing how this works.
The fancy tools and frameworks don't matter if you skip these steps. I've seen great automation built with shell scripts and terrible automation built with the latest platform. It's not about the tool. It's about thinking through what you're doing and planning for when it fails.
Because it will fail. The question is whether you're ready for it.