I've been automating stuff since before it was cool, and I've learned one thing the hard way: the moment you skip the boring questions is the moment you build something that works for two weeks and then becomes someone else's problem.
This checklist isn't about tools or frameworks. It's about the decisions that actually matter when you're building something you expect to last. I use this before I write a single line of code, a single Terraform config, or a single workflow. It's saved me more time than any automation tool ever has.
—
The Pre-Flight Questions
Before anything else, answer these three:
Who is this for? Not "what does it do" — who sits in front of it? If you can't name the actual person, you're building for yourself, and that's fine, but know it.
What happens when it breaks at 2am? This is the question most people skip because they're excited about the happy path. If your automation fails, does someone get paged? Does it retry safely? Does it leave the system in a worse state than before it ran? The answer better not be "I guess I'll check the logs in the morning."
How will you know it worked? Metrics, logs, a Slack notification, a database flag — something. If you can't verify success without SSHing into a box, you've already lost.
These questions sound obvious. They're not. I've seen entire CI/CD pipelines that nobody could explain who actually used them, and I've found automation running in production that hadn't worked in months because nobody was checking the output.
—
The "Will This Still Work in 6 Months" Test
This is where most automation dies. It works great on day one, then something changes — a dependency updates, an API token rotates, a teammate leaves — and suddenly it's broken and nobody notices.
Pin your dependencies. Not just in code, but in your head. If your automation calls an external API, know what happens when that API changes. I've seen scripts break because a cloud provider changed their response format. Version pinning isn't paranoia; it's operational hygiene.
Document the manual steps. If there's anything a human needs to do to keep this running — a token refresh, a manual approval, a cleanup job — write it down. Not in a wiki that nobody reads. In the same place the automation lives. If it's a cron job, put the instructions in the cron comment. If it's a GitHub Actions workflow, put it in the workflow file. The context dies when you do.
Plan for the person who inherits this. That person might be you in six months after you've forgotten everything. Write the runbook like you're handing it to someone who has half your knowledge and twice your suspicion. They should be able to understand what the automation does, why it exists, and how to debug it without reading your mind.
—
Failure Modes Nobody Talks About
Here's what actually breaks in production:
Timeouts on long-running operations. Your automation fetches 10,000 records from an API. The API times out at 60 seconds. Your script retries. Now you're hammering the API and potentially creating duplicate records. Set timeouts appropriately, build in backoff, and idempotency is not optional.
Credential rotation. In 2026, most of us use short-lived tokens from identity providers. If your automation runs on a schedule and the token expires between runs, it will fail. I've seen nightly jobs die silently for weeks because the service account password rotated and nobody got paged. Use workload identity, short-lived tokens, or whatever your cloud provider offers — but test the renewal path.
Silent failures. Your script runs, exits with code 0, but didn't actually do anything because a condition wasn't met. This happens more than you'd think. A find command that returns nothing is still a successful exit. Check the output, not just the exit code.
State drift. If your automation modifies state — creating resources, updating records, changing configs — something will eventually conflict with manual changes someone made in production. The automation doesn't know about the manual fix, runs again, and overwrites it. Version control your state, detect drift, or accept that manual overrides will get clobbered.
—
The Maintenance Reality
Automation is not "set it and forget it." It's more like a garden — it needs tending, and the weeds show up faster than you expect.
Schedule regular reviews. Every 90 days, look at what your automation actually did. Check the logs, check the outputs, check if the external systems changed. I've found automation that was "working" but producing garbage output because an upstream API changed its response format six months ago.
Test your backups. If your automation can destroy data, test the recovery path. I've written scripts that cleaned up old records based on age. One bad date calculation later, I had a very bad day. Test with small datasets first. Always.
Watch for drift from the happy path. The more your automation runs, the more edge cases you'll find. Someone will have a weird filename, a non-standard timezone, a missing field. Build in logging for these. They're not failures — they're information about where your automation needs to get smarter.
—
What I Would Do First
If you're starting a new automation project, here's what I'd do before writing any code:
- Write a one-paragraph description of what this does and why it exists. If you can't do this clearly, you don't understand the problem yet.
- Identify the failure modes. Write down three things that could go wrong. For each one, decide whether the automation should fail loudly, retry silently, or skip gracefully.
- Pick one small piece and automate that first. Don't build the whole thing. Automate the simplest path end-to-end, get it running, verify it works. Then add complexity.
- Set up alerting before you set up scheduling. If you can't be paged when it breaks, don't put it in production.
- Walk away for a day and come back. Read what you wrote as if you'd never seen it. Does it make sense? Would a teammate understand it? If not, refactor before you ship.
That's it. No frameworks, no templates, no vendor solutions. Just five questions that will save you from building something that becomes technical debt before it ever runs in production.