Here’s how it came together.

Starting from scratch with Claude Code

I’ve been spending a lot of time in Claude Code lately, and I wanted to push past the daily email (which is still humming along on Substack) and build something new. So today I sat down to build a personal site from scratch. No templates. No themes. No Wix or Squarespace. Just me, the terminal, and Claude Code.

My prompt was simple: I want a minimal, editorial site with a link to my Substack newsletter, an automated AI blog (which I’ll wire up to n8n down the road), an about section, and a contact form. Clean. Quiet. Typography-first.

Claude Code spun up an Astro project with TypeScript, Tailwind, and MDX. It gave me back exactly what I asked for, plus one section I didn’t ask for: a Projects page meant to highlight what I’m building. I almost cut it, but then I realized: this site is the project I’m building right now. So it stays. I’ll fill it in as I go.

Total cost for the initial build: under $10 in Claude API credits.

Then I handed the code to Codex

Here’s the part I want to spend more time on, because I think this is the real unlock.

Once Claude Code had finished the initial build, I opened a second terminal window (same Mac, just another tab) and pointed OpenAI’s Codex at the same repo. Same code, different model, different review. I wanted a second AI to QA what the first AI had written.

Codex caught things Claude hadn’t flagged. One example: my homepage pulls the latest posts from Substack via their feed, with placeholder posts as a fallback in case the feed ever fails. Codex pointed out that those placeholders, “Placeholder essay one, Placeholder essay two, Placeholder essay three,” would render on the live site if Substack ever hiccupped. Not a great look. The fix was simple: gate the placeholders behind a development-only flag and show a proper empty state in production. Claude Code agreed and shipped the change.

That was one of eight fixes Codex flagged. Some were security-related, some were accessibility improvements, some were schema cleanups. All of them were issues I would never have caught on my own. And importantly, ones Claude hadn’t surfaced either.

That workflow, building with one model and reviewing with another, feels like something I’m going to keep doing. It’s the AI equivalent of getting a code review from a colleague who thinks slightly differently than you do. Next project, I might flip it: have Codex write the first draft and Claude Code review. I’m curious whether the strengths reverse.

For this build, I only did one review pass before shipping. I could’ve gone deeper, but it’s a simple static site. The real complexity will come when I start wiring the blog up to n8n for automated publishing.

Shipping it

Once the fixes were in, I committed to GitHub and connected the repo to Vercel. A few rounds of copy edits (bio, about section, headlines) and the site was live. The whole end-to-end process, from empty directory to public URL, took less than a day.

What I’m taking away from this

A few things stuck with me from this build:

• Watching the API meter run was eye-opening. We’ve been talking about the economics of AI-built products in one of my Maven classes, but seeing it line up in real time, under $10 to scaffold a real, deployable site, makes the math hit differently than any slide deck ever could.

• Running two coding agents side by side on a Mac was surprisingly seamless. Two terminal tabs, one building, one reviewing. No framework, no plugins, no fancy orchestration layer. Just two AIs, one repo, and me in the middle.

• Claude Code’s default design choices were more than serviceable. I went MVP just to stand the site up. Clean, restrained, no AI-startup gradient nonsense. I’ll loop back with Claude Design to push the visual layer further once the foundation is solid.

What’s next

This is the foundation, not the finished product. The big build is the AI blog: I’m planning to use n8n to scrape AI and digital marketing content from YouTube and other sources, generate posts, and publish them automatically to the new blog section. That’s where things get expensive. And that’s where things get interesting.

Go check out kenashe.ai, subscribe to the newsletter if you haven’t, and follow along. I’ll be sharing the n8n build next.

I’m on the Pro plan, and I’ve been keeping a close eye on my usage. If you didn’t know this (and a lot of people I talk to don’t), you can actually monitor your Claude usage in real time at claude.ai/settings/usage. I’ve been checking it constantly.

What the Usage Page Actually Shows

The page breaks your usage into three buckets, which is genuinely useful once you understand what you’re looking at:

• Current session limits, your rolling 5-hour window

• Weekly limits across all models, the broader ceiling that resets seven days after your session starts

• Claude Code plus additional features, a separate bucket that accounts for things like agentic runs

Right now my current daily limit is at 66% and my weekly limit is at 43%. Watching those numbers tick up in real time has actually changed how I prompt. I’m more deliberate. I start fresh chats more often instead of letting one giant thread balloon. Long threads burn tokens faster because Claude has to re-read the whole conversation every turn.

The “Extra Usage” Toggle

I’ve also turned on extra usage. This is the setting that lets you keep going after you hit your plan’s limit. Instead of stopping cold, you opt in to continue at standard API rates with a monthly spend cap you control.

I turned it on because I’m still on Pro and I’m not quite ready to jump to Max. Hitting a wall mid-session and having to wait it out kills momentum. Paying a little for overflow felt like the right tradeoff for now.

How I Balance Load Across Claude: Using the API for Claude Code

Here’s a strategy I’ve landed on that works well: I use the Claude API for Claude Code, separate from my Pro subscription.

Pro covers chat, Projects, and Cowork, all of which share the same usage pool. Claude Code is the heaviest token consumer in my workflow by a wide margin, so if I run it through the same Pro plan, it eats my limits before I’ve done anything else.

By routing Claude Code to the API and paying per-token, I keep all the other surfaces (chat, Projects, Cowork) running smoothly inside my Pro budget. Yes, the API is more expensive in the moment, but it means I’m not hitting walls across the entire Claude ecosystem just because I had one heavy coding session.

It’s basically load balancing for my own usage.

Tips to Stretch Your Tokens

A few habits I’ve picked up that genuinely help:

• Use Projects. This is my biggest one. I love Projects. They’re a great way to save context, build “experts” for specific topics, and store examples of the kind of output you want. Instead of pasting the same long context into every new chat, you set it once and Claude carries it forward. Massive token savings, plus way better answers.

• Start fresh chats more often. A long thread isn’t free. Claude re-reads the whole history every turn. When you’ve shifted topics, open a new conversation.

• Don’t paste the same document twice. If you’re going to reference it again, that’s what Projects are for.

• Use the right model for the job. Not everything needs the most powerful model. Routine reformatting, quick lookups, and simple Q&A don’t need to burn through your premium budget.

• Watch the usage page before big sessions. If you’re at 70% on a Tuesday, plan accordingly.

Why I Haven’t Upgraded to Max Yet

The honest reason - I already pay for a lot of AI tools.

• ChatGPT (OpenAI)

• Gemini

• Grok

• n8n

• ElevenLabs

• OpenRouter credits

Adding another $100 to $200 per month on top of all that has been a hard sell. For context, Claude Max comes in two tiers: Max 5x at $100/month (5x the usage of Pro) and Max 20x at $200/month (20x the usage of Pro).

What I Actually Use Each Tool For

I get asked this a lot, and the answer isn’t a clean one. Part of the reason I have all these subscriptions is that I genuinely want to try different things in each. But here’s how it’s shaken out in practice:

• Claude. Claude Code is where it really shines for me right now. That’s my main use case.

• ChatGPT. I find it very useful for Codex. Different strengths, different workflow.

• Gemini. This is my daily Q&A app on my phone. I’ve basically replaced Google search with Gemini. When I need to answer something on the go, I’m opening Gemini, not Google.

• Grok. I got access through X and don’t use it daily, but I find it refreshing when I want to dig into an area that other apps consider too sensitive or unethical to engage with. Grok doesn’t seem to have those concerns. If I hit a wall on another model, I immediately go to Grok and usually get a great answer.

• n8n and ElevenLabs. Totally different use cases (automation and voice respectively). These aren’t really “redundant” with the LLMs. Same will be true for Higgsfield once I add it.

Here’s the thing: the best models from all the major LLM providers are all very good at this point. In theory I could consolidate down to one. But I really don’t want to. I have legitimate use cases for each, and I find it genuinely powerful to have all of them at my disposal.

The Break-Even Math on Max

The math is actually pretty straightforward:

If you’re spending $20/month on Pro plus another $80 or more in extra usage (or API tokens), you should just get Max 5x at $100/month.

That’s exactly where I expect to land. I’m not there today because I bought a chunk of extra usage credits and I want to use those up first. Once I burn through them, I’m 100% switching to Max. Same dollars, fewer interruptions, no per-token accounting in my head.

The Real Cost of Hitting Limits

This is the part nobody talks about enough: the cost of hitting your limit isn’t dollars, it’s momentum.

When you’re deep in a project and Claude tells you to come back in three hours, you don’t just lose those three hours. You lose the mental state you were in. You lose the thread of where you were going. You come back to a project that’s gone cold, and you have to rebuild context for yourself, not just for the model.

This is literally why I bought extra usage credits. Not because I couldn’t afford to wait, but because I couldn’t afford to context-switch. Stopping mid-thought to deal with a usage wall is way more expensive than the $20 or $50 of overflow tokens that would have kept me moving.

If you’re using Claude for real work, that’s the number that should drive your decision, not the sticker price of Max.

Still on the Roadmap

I don’t pay for Higgsfield yet, but that’s the next service on my list to evaluate.

If you’re using Claude more than casually, bookmark the usage page. It’s the difference between guessing what your workflow costs and actually knowing.

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:

1. Stoic philosophy

2. Meditation and mindfulness

3. Nutrition

4. Communication skills

5. Humor

6. Golf tips for a scratch golfer

7. 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:

1. It’s native to macOS, so it’s fast and plays nicely with the rest of my system.

2. 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.

Not on AI engineering. That’s not where I’m headed.

In her book AI Engineering, Chip Huyen describes the AI engineering stack as having three layers: application development, model development, and infrastructure. I’m focused on the top layer, application development. That’s the part anybody can do today, using the models that already exist. It’s about giving a model good prompts and the right context to produce real, usable results.

And honestly, that’s what makes this moment so exciting. You don’t need to train models or build infrastructure to create something useful. Anybody can pick up the tools and start building. That’s the part I plan to live in.

The space is moving fast. I believe we’re heading toward a future where everyone will need to know how to leverage AI, and I’d rather be early than have to catch up later.

The plan: 20 hours a week, 8 weeks

For the next eight weeks, I’m dedicating 20 hours a week to AI, with a deliberate balance.

The priority is building. Most of that time goes into actually using the tools, shipping projects, breaking things, and iterating. That’s where the real learning happens.

Alongside the building, I’m doing two things to keep the foundation solid:

• Taking a class (more on that below)

• Reading AI Engineering by Chip Huyen

The reading and the class are supplemental, but they’re not optional. Building without context produces shallow skills; theory without building produces no skills at all. I want both.

I’m also fortunate to be at a point in my business where I can step back briefly and invest this kind of time into developing new skills. That window doesn’t come around often, and I don’t want to waste it.

Why I’m documenting it here

I’m going to document the entire process on this Substack: the wins, the failures, the projects, and the lessons along the way.

Two reasons for that:

1. Sharing the journey. If anything I do here helps someone else figure out their own path into building with AI, that’s a great outcome.

2. Solidifying my learning. Writing forces me to slow down, review what I did, and actually understand it. The act of documenting is part of the learning itself.

Where I’m starting from

I’m not starting at zero. I’ve been prompting AI extensively for a while now (from work projects to planning vacations), and I’ve taken a couple structured AI courses through Maven, which has been my go-to platform for this kind of learning.

So far, I’ve completed two Maven certifications:

• AI Prototyping for Product Managers

• How to Scale a Business With Agentic Workflows (by AI Build Lab)

  

  

And I’m currently in the middle of:

• Course: OpenClaw & Claude Code Certification for AI-Native PMs (by AI Product Academy, taught by Dmitry Shapiro and Dr. Marily Nika)

• Book: AI Engineering by Chip Huyen

Honestly, it’s this third class that pushed me from “I should really do this” to “I’m doing this now.” The combination of OpenClaw and Claude Code is opening my eyes to what’s possible when you can actually design, build, and ship AI agents without being a traditional engineer. I want to spend serious time exploring it.

What’s next

I’ll be posting regularly here as the sprint unfolds. I’ll also be sharing progress on LinkedIn and X along the way.