I Spent $8,857 Using Claude Code to Build 6 Projects. Here's What I Learned.

Not a sales pitch. I just noticed there's almost no deep-use experience with Claude Code on Dev.to or Reddit — mostly "look I built a todo app" posts. After burning through nearly nine grand, I have some real data to share.

The Numbers

14 days. $8,857.62. 3.884 billion tokens. 47,235 API requests. All on Claude Opus 4.8 (1M context window).

You probably think I'm insane. Honestly, when I saw the bill after week one, I panicked a little too. But here's the math: I was pushing 6 projects simultaneously, 2 of which were full-stack production apps. At freelance rates of $150/hr, these projects represent 4-5 weeks of work.

The spending wasn't linear. First 3 days cost about $800 — still figuring out how to use the tool effectively. Two peak days hit $800+ each — June 18 alone was $828.74, running security hardening on a SaaS app and debugging a video pipeline in parallel. The last few days dropped to ~$300/day, because once the configuration was dialed in, back-and-forth conversations dropped dramatically.

Here's the rough breakdown by project:

A counterintuitive truth: caching is where all the tokens go.

Most people assume tokens are split between "input + output." Wrong. Look at my actual billing structure:

Cache hit rate: 86.4%. This means the vast majority of my 3.8B tokens were repeatedly reading the same context — project files, CLAUDE.md, conversation history. Cache hit tokens cost 1/10th of new input tokens. Without caching, this bill would be several times higher.

This is why the gap between "knows what they're doing" and "winging it" can be 5x in cost — skilled users keep cache hit rates high, while careless users thrash the context and invalidate the cache every few turns. (How to maximize cache hits is covered in depth in Module 2 of the manual.)

What does a single request actually cost?

I pulled some line items from my billing detail. Same model, Opus 4.8:

• 212 input tokens, 1,397 output tokens = $1.91, took 104 seconds
• 514 input tokens, 7 output tokens (a simple confirmation) = $0.45, took 2 seconds

See the pattern? Output tokens cost 5x more than input (Opus 4.8: $15/M input, $75/M output). So getting Claude to skip the explanations and just write code saves real money — a 2,000-line response with verbose commentary costs several times more than 500 lines of clean code. That's why my CLAUDE.md explicitly says "be concise, don't explain things you weren't asked about."

Why Opus 4.8 instead of Sonnet?

Simple rule: if the task would take me more than 2 hours of thinking time to do myself, use Opus. If it's grunt work (batch file changes, adding comments, writing tests), Sonnet is fine.

Opus is noticeably better at architectural decisions. For example, LightCraft's multi-engine failover — when Runway's API times out, automatically switch to Kling while ensuring credits are only deducted once — that kind of design involving state management and edge cases, Opus nails it on the first try. Sonnet might need 2-3 rounds of corrections.

But Sonnet has better cost-efficiency on simple tasks. My workflow now is to configure two profiles in settings.json and switch based on task complexity.

6 Projects: What Was Worth It, What Wasn't

1. LightCraft V2 (Image-to-Video SaaS) — Worth It

The most expensive project, and the highest ROI. A complete Next.js full-stack app: user auth, credit top-ups, video generation, security hardening.

Several areas where Claude's output was better than what I'd write myself:

• OWASP security hardening (CSRF tokens, rate limiting, input sanitization)
• Credit system transaction consistency (deducting credits and creating tasks must be atomic)
• Multi-engine failover logic (Runway → Kling → Veo fallback chain)

Conservative estimate: saved 3 weeks of development time. The concurrent credit deduction problem alone would've taken me days to get right.

2. Psychology Quiz App (sbti2) — Worth It

4 hours from zero to deployed. Includes Framer Motion page transitions, radar chart visualization, QR code sharing. This kind of "small but polished" project is Claude Code's sweet spot — clear requirements, well-defined scope, done in an afternoon. My entire prompt was one sentence: "Build a psychology assessment app where users answer questions and see a radar chart with detailed analysis, with screenshot sharing support." It chose the tech stack, scaffolded the project, and wrote all the code. I only changed the color scheme twice.

3. AI News Video Pipeline — Worth It

This project has the most lasting ROI. Claude helped me build an automation pipeline: RSS news scraping → LLM rewrites into voiceover scripts → TTS audio generation → auto-matched visuals → FFmpeg video assembly. Now producing a daily tech news brief takes 30 minutes of human involvement, mostly spent reviewing content quality rather than technical operations.

One detail worth mentioning: if a video covers a specific product, it must include real product footage — no faking it with text cards. Claude wrote the YouTube video download + clip extraction logic, and if the download fails, it stops production on that video entirely instead of quietly substituting a placeholder image. This "nothing rather than something fake" logic was explicitly specified in my CLAUDE.md.

4. NZ WHV Visa Slot Grabber — Half Worth It, Half Not

The Playwright automation was clean: auto-filling forms, CAPTCHA wait logic, retry mechanisms, even network timeout recovery with checkpoint resumption. But New Zealand Immigration uses ASP.NET Web Forms with __VIEWSTATE and __EVENTVALIDATION hidden fields that change on every form submission. Claude's first version hardcoded these values — instant 500 errors. After I pointed this out, it switched to dynamic parsing, but then stumbled on multi-step form state management. Took 5-6 rounds to stabilize.

Lesson: the older and more obscure the tech stack, the more mistakes Claude makes. Its training data has far more React docs than ASP.NET Web Forms. If your project involves legacy tech, expect 30-50% more debugging time.

5. Developer Tutorial — Worth It, With Caveats

Claude has a habit of over-explaining when writing documentation. A simple export https_proxy=http://127.0.0.1:7890 command gets 200 words of background context. I had to repeatedly emphasize "be concise" in CLAUDE.md to keep the word count under control.

6. img2video-demo — Not Really Worth It

Just calling an API, displaying results, handling errors. For this level of complexity, writing it yourself is probably faster — the time spent describing requirements to Claude is already enough to write the code yourself.

Bottom line: Claude Code's sweet spot is "medium complexity + clear requirements." Too simple and it's not worth the overhead. Too complex and it loses control.

What Free Tutorials All Miss

90% of Claude Code tutorials online cover installation and basic usage. "How to install," "how to chat," "how to make it edit code" — you can pick this up in 5 minutes without a tutorial.

What actually separates productive users from the rest is configuration, and almost nobody covers this properly.

settings.json Accounts for 80% of the Productivity Gap

For example, most people don't know you can set effortLevel:

// ~/.claude/settings.json
{
  "preferences": {
    "effortLevel": "xhigh"
  }
}

Then there's permission configuration. By default, Claude asks for confirmation every time it runs a shell command. If you're on your own dev machine, you can allowlist common commands:

{
  "permissions": {
    "allow": [
      "Bash(npm run *)",
      "Bash(git status)",
      "Bash(git diff *)",
      "Bash(ls *)"
    ]
  }
}

This one config change alone cuts interaction interruptions by 50%+.

CLAUDE.md Isn't Just "Please Use TypeScript"

My CLAUDE.md is nearly 80 lines. The most important part isn't the tech stack declaration — it's the behavioral constraints:

## Coding Principles
- If 200 lines of code can be written in 50, rewrite it
- Don't add features beyond what was requested
- Don't create abstractions for one-off code
- Read related code before modifying — understand context first
- Every line changed must trace directly to the user's request

Without these constraints, Claude will bolt on things you never asked for: config file managers, custom exception hierarchies, over-abstracted factory patterns...

The Hooks System Is Almost Never Discussed

Claude Code has a hooks mechanism (PreToolUse, PostToolUse, Notification, etc.) that runs scripts automatically before or after specific operations. For example, I configured a PostToolUse hook that auto-runs eslint --fix after Claude edits a frontend component file — saves me from repeatedly reminding it to fix formatting. You can also use PreToolUse to intercept dangerous operations, like blocking it from deleting directories outside node_modules. Once this system is configured, a lot of repetitive checking and formatting happens automatically. But the official docs cover it in just a few paragraphs — most configuration patterns you have to figure out by reading source code or trial and error.

5 Hard-Won Lessons

Lesson 1: Setting effortLevel to xhigh Changes Everything

At the default effort level, Claude tends toward "it compiles, ship it" code. Set it to xhigh and it proactively considers edge cases, writes more complete error handling, and even adds comments explaining design decisions.

Yes, each request costs more. But code that's right on the first try vs. code that needs 5 rounds of fixes — xhigh is actually cheaper in total. I had an API route that took 4 rounds at default effort, each round a half-baked fix. After switching to xhigh, similar tasks were consistently done in one round.

Lesson 2: "Don't Over-Engineer" in CLAUDE.md Is Worth More Than Anything

Claude has over-engineering in its DNA. Whatever you ask for, it wants to add abstraction layers. You want a simple API call, it gives you a strategy pattern + dependency injection + custom exception hierarchy.

After adding this to CLAUDE.md:

Don't add features beyond what was requested
Don't create abstractions for one-off code
Don't add "flexibility" or "configurability" that wasn't asked for

Code quality went up a level. Not by becoming more complex — by becoming simpler.

Lesson 3: Honeypot Anti-Bot Fields Will Block Real Users

When building login security for LightCraft, Claude suggested adding a honeypot field — a CSS-hidden form field that humans can't see and won't fill in, but bots will auto-fill, flagging them as bots.

Logically perfect.

But after deploying, I discovered that 1Password, Bitwarden, and other password managers also auto-fill hidden fields. Real users were getting blocked as bots.

Claude won't warn you about this, because it doesn't know your users use password managers. AI-generated code can be logically correct but fail in real user scenarios. You must do your own scenario testing.

Lesson 4: Don't Be Too Generous With Daily Rewards

This one isn't about code — it's about product design.

When designing the credit system, I had Claude implement "10 credits per daily check-in." That's 300 credits per month. But the paid Pro plan only gave 200 credits/month.

Free users were getting more than paying customers.

Claude won't question your business logic. You say daily reward is 10, it writes dailyReward: 10. It won't speak up and say "why would anyone pay then?"

Product design is your job. Claude just implements. I later adjusted check-in to 3 credits/day and Pro to 400/month. Then the model worked.

Lesson 5: Platform Rules Are AI's Blind Spot

Here's a very specific gotcha: when integrating a cloud SMS service, Claude used the standard SMS API. Code was textbook. But my account type couldn't send marketing SMS — that's a platform policy restriction, not a technical issue.

Claude doesn't know about these restrictions. It only knows how to call APIs, not whether your account is authorized to call them. Platform policies, terms of service, and account-level restrictions are blind spots for AI — especially third-party service APIs with tiered access.

Always verify your account permissions and service quotas before letting Claude write integration code. A perfectly-written API call that your account can't execute is wasted work.

Was It Worth $8,857?

Honestly, the answer depends on where you are:

• If you're just curious: No. Use the free tier, or run Sonnet for small tasks. Don't start with Opus — that's pure money burn.
• If you're seriously building something with a ship date: Yes. $8,857 bought back at least 4 weeks of full-stack development time. The security hardening, transaction consistency, and failover code Claude wrote is better quality than what I'd produce under deadline pressure.
• If you know how to configure it: ROI doubles. Same model, same Opus — a configured user vs. an unconfigured user, productivity gap is 2-3x. Someone with a properly tuned CLAUDE.md and settings.json could probably hit my $8,857 output level for ~$3,000 — because a big chunk of my first $2,000+ was burned during the "teaching Claude how to work with me" phase.

The limiting factor isn't the model's capability. Opus 4.8 is genuinely powerful. But if you don't configure settings.json, don't write a real CLAUDE.md, don't know when to switch to Sonnet, and don't understand how hooks can eliminate repetitive manual checks — you're just burning money. The tool's ceiling is determined by the user's configuration skill, and nowhere is this more obvious than with Claude Code.

A Free Gift

Here's the core CLAUDE.md template I actually use, copy-paste ready:

# Project Name

## Coding Principles
- If 200 lines of code can be written in 50, rewrite it
- Don't add features beyond what was requested
- Don't create abstractions for one-off code
- Every line changed must trace directly to the user's request
- After making changes, explain what changed and why

## Tech Stack
- Next.js 16 + React 19 + TypeScript
- Tailwind CSS 4
- Prisma + SQLite
- Deploy: Vercel

## Don'ts
- Don't "improve" adjacent code, comments, or formatting
- Don't refactor things that aren't broken
- Don't add error handling for scenarios that can't happen

And a starter settings.json:

{
  "preferences": {
    "effortLevel": "xhigh"
  },
  "permissions": {
    "allow": [
      "Bash(npm run *)",
      "Bash(git status)",
      "Bash(git diff *)",
      "Bash(ls *)",
      "Bash(cat *)"
    ]
  }
}

The full configuration deep-dive, 5 settings.json templates, 8 cheat sheets, and architectural breakdowns of all 6 projects are in The Claude Code Field Manual.