I Spent Three Weeks Trying to Make My Script Run Automatically. Here Is Every Dead End I Hit.

I am not a developer. I work in product, I have never written code professionally, and until about six months ago I assumed that building software was something other people did. Then I discovered that ChatGPT and Claude could write Python scripts for me, and suddenly I was building things I never thought I could build. A morning briefing email. A finance tracker. A Reddit scraper that summarised what my customers were saying. The building part turned out to be the easy part. Making any of it actually run automatically, without me sitting there pressing go, took three weeks of dead ends and one very anticlimactic solution.

This is that story.

Week One: “I Will Just Leave My Laptop On”

The first script I wanted to automate was my morning briefing. Every morning I wanted an email summarising my calendar, the weather, and a few news headlines. Claude wrote the script in about fifteen minutes. It worked perfectly when I ran it manually.

My first solution was elegant in its naivety: I would just leave my laptop on overnight.

This worked exactly once. The second night my laptop ran an update and restarted. The script did not run. The third night I forgot to plug it in and it died at 2am. The fourth night it worked. The fifth night the internet dropped at 4am and the script failed silently.

Leaving your laptop on is not a solution. It is a hope.

Week One, Continued: Discovering That Cron Jobs Exist

A developer friend told me I needed to use cron jobs. I Googled “cron job.” I immediately felt out of my depth.

The tutorials assumed I knew what a terminal was, what SSH meant, what a server was and how to rent one. I knew none of these things. I spent two days reading before I understood enough to be confused at a higher level.

I did manage to set up a cron job on my laptop. It ran the script at 8am the next morning while my laptop was open and I happened to be watching. It felt like a miracle. Then I closed my laptop and went to a meeting and the script did not run the next day.

Cron jobs on a laptop have the same problem as leaving your laptop on. They stop when your laptop does.

Week Two: AWS

My developer friend, now slightly impatient, told me I needed to put my script on a server. He recommended AWS Lambda.

I will not document everything that happened during my AWS week in detail because some of it is embarrassing. I will say: I created an account, I was immediately overwhelmed by the number of services, I found a tutorial that seemed relevant, I followed it for an hour, and I ended up with something that technically existed in AWS but did not run my script in any way I could verify.

AWS is not built for me. It is built for infrastructure engineers at companies with dedicated DevOps teams. The documentation assumes you already know what IAM roles, VPCs, and execution environments are. I did not know any of those things. I still only vaguely know what they are.

I closed the AWS console and went for a walk.

Week Two, Continued: Heroku

A different developer told me to try Heroku instead. Heroku was better. I could see what I was doing. I got my script deployed.

Then I found out Heroku removed their free tier. The paid tier was more than I wanted to spend on a personal morning briefing email. I moved on.

Week Three: GitHub Actions

I stumbled onto GitHub Actions through a Reddit thread where someone described my exact problem. The responses pointed me to GitHub Actions. I was sceptical because I had never really used GitHub for anything beyond storing code.

I asked Claude: “Can you write a GitHub Actions workflow file to run my Python script every day at 7am and email me a summary?”

Claude wrote the entire configuration file, told me exactly where to put it, and explained what each section did.

I committed the file. I waited until the next morning. The email arrived at 7:02am.

I did not do anything technical. I asked an AI to write a configuration file, put it in the right folder, and it worked.

What I Learned From Three Weeks of Dead Ends

The laptop approach fails immediately. Any automation that depends on your laptop being on and awake will break constantly. Accept this early and save yourself a week.

The right tool depends on what you built. For a Python script that runs on a schedule, GitHub Actions is the simplest free solution. For a web app that needs to be always available, Vercel or Netlify are far easier than AWS. For someone who wants zero configuration at all, tools like Snapdock exist specifically to handle the infrastructure so you do not have to think about it at all. → Snapdock

Ask your AI to write the configuration, not just the code. This was the thing I did not know to do for the first two weeks. Claude and ChatGPT can write GitHub Actions workflows, deployment configurations, and cron expressions just as easily as they write Python scripts. The same tool that built the thing can tell you exactly how to run it.

The documentation assumes prior knowledge you might not have. Every tutorial I found during those three weeks assumed I knew something I did not. This is not a personal failing. It is a gap in how deployment is taught. The missing piece is usually someone saying “here is the actual sequence of steps, starting from the very beginning, with no assumed knowledge.”

That is what this blog tries to be.

The One Thing to Remember

Getting a script to run automatically is harder than building the script, and it does not need to be. The tools have improved enormously. GitHub Actions handles scheduled scripts for free. Vercel handles web apps with almost no configuration. If you want zero setup, Snapdock was built for exactly this gap. The three weeks I spent on dead ends would have been three hours with better information. You have that information now.

Ready to skip the dead ends? → Snapdock

New here? These might help: The complete guide to running your app automatically. No developer required. → Why does my script stop when I close my laptop? →