My First Build with Claude Code: A Daily Email from Me, to Me
On Monday I did my first build with Claude Code. It failed. Then it worked. Then it failed again.
For context: I’m not an engineer. I mostly use Windows, and I bought a Mac Mini for the sole purpose of playing with AI.
What I tried to build
A daily personal email, sent to me every morning at 6 AM, that includes:
The day’s forecast
A dad joke
A few stock tickers
300–400 words on a topic that rotates by day of the week
The seven topics:
Stoic philosophy
Meditation and mindfulness
Nutrition
Communication skills
Humor
Golf tips for a scratch golfer
AI learning tips
How I accessed Claude Code
There are a few ways to use Claude Code. The two easiest are the terminal on a Mac, or the Claude desktop app.
I went with the terminal for two reasons:
It’s native to macOS, so it’s fast and plays nicely with the rest of my system.
I’m not locked into the Claude app. I can use the terminal with Codex or any other major LLM coding agent.
What went well
Building the daily email with Claude Code was surprisingly straightforward. I bounced between Claude Code in the terminal and Claude in the desktop app to think through the design, then let Claude Code actually write the thing.
The solution it landed on was a Python script that runs locally on my Mac Mini and fires at 6 AM each day. I:
Set up a dedicated email address for Claude Code to send from
Hooked up APIs for weather and stock tickers
Let Claude generate the 300–400 word section based on the day of the week
I tested it manually. The email fired. The right topic showed up for the right day. The dad joke even landed:
Did you hear the joke about the wandering nun? She was a roaming catholic.
Looked good.
Where it failed
The next morning I woke up at 6, checked my inbox… nothing.
It turned out the original setup didn’t have the right macOS permissions to run the script on its own at that time. Not something I could have caught in a manual test, as it only failed when it had to fire on a schedule, unattended.
The solution
I went back to Claude in the desktop app, told it the email never showed up, and walked through possibilities. The fix was to remove the cron job and replace it with a launchd agent.
I’ll be honest: I don’t know the deep technical difference between those two, and at this stage I don’t really need to. I made the changes Claude suggested, and the next morning at 6 AM the email landed in my inbox.
How long did this take?
About three hours, all in.
That sounds like a lot for something this simple, and it would have been much faster, except:
I was deliberately going slowly - reading the Python scripts Claude Code wrote and making sure I actually understood what was happening, instead of just rubber-stamping it.
I had to set up a fresh email account from scratch for this project.
That fresh account got me into trouble with Google. I was firing so many test emails from a brand-new sender that Google flagged it, and not in the normal “check your spam folder” way. The emails were hidden from my personal inbox entirely, not even visible in spam. Took some troubleshooting to figure out what was happening.
The three hours also covers the next morning’s debugging when the 6 AM run didn’t fire.
For three hours of work, what I got was a thing that runs on its own every day, forever. That math feels pretty good.
Then it failed again
A few days later, 6 AM came and went. No email.
This time the problem wasn’t permissions. It was fragility. The weather API I was pulling from happened to be down that morning. My Python script tried to fetch the forecast, the call failed, and the entire email failed with it. One missing piece took down the whole thing.
I went back to Claude Code, described what happened, and asked it to diagnose. It walked through exactly what had gone wrong and proposed a fix: instead of letting a single failed API call crash the script, the weather fetch now fails gracefully. If the API is down, the email still goes out, just without that day’s forecast.
The bigger lesson is one I think every first-time builder runs into: making something work is one problem; making something resilient is a different one. The first version of this assumed every API call would succeed. The second version doesn’t.
What I’d do next
Getting a daily newsletter written by me, for me, is genuinely cool. I’m going to keep iterating:
Add more tickers
Rotate or expand the daily topics
Maybe add a comic strip if I can find one I like
After the weather API outage, the QA idea I’d been kicking around feels less optional. The plan is to run this project through Codex as a code review pass — point a second coding agent at what Claude built and see what fragility it catches. Claude builds, Codex reviews, or vice versa. Both failures so far were ones I could only catch at runtime; a second set of eyes might surface the next one before it bites.
Final thought
I can’t speak to the quality of the underlying code or whatever tech debt I might be racking up. But for a first build, at my level of experience, the bar was simple: does it work?
It does. And that feels like a real unlock.