Build a SaaS solo, and make more from it than you spend on Claude Code. That was the entire goal. I kept a running log for 90 days starting in February 2026, and this article is that log made public.
This isn't a success story polished for social media. It includes the wrong turns, the bad calls, and the tokens I burned for nothing — because those parts are where you'll find the most useful signal.
1. Why Claude Code?
"Why not Cursor?" is the first thing people ask. I asked it too, for a while.
What changed my mind was a bug fix session. Claude Code traced the impact across multiple files, rewrote the tests, and staged a commit — autonomously, without me orchestrating each step. Cursor excels at in-editor completion, but Claude Code thinks through work. For SaaS development where dependencies get tangled fast, that difference is meaningful.
The other reason was cost transparency. Claude Code runs on Anthropic API usage billing, so I always knew exactly what I was spending and why. Flat-rate tools obscure that feedback loop. As an indie developer, cost awareness is directly tied to profit margin.
2. Choosing the Product (Day 1–7)
The first week went entirely to product selection. I used three filters.
① Something I'd use every day
The most reliable demand signal is whether you personally need it. I picked a unified dashboard for managing sales, reviews, and rankings across multiple App Store products.
② A stack where Claude Code excels
Next.js + TypeScript + Stripe + Cloudflare Workers. I chose this because Claude Code is deeply familiar with it — error self-correction rates are high, and generated code rarely needs major rework. If I'd gone with Ruby on Rails or Django, the learning cost and debugging overhead would have compounded.
③ Monetizable complexity within three months
I designed for "small start, charge early." The plan wasn't to finish and then add billing — it was to ship the first paid feature on Day 30 and work backward from there.
3. MVP Design — A Week of Architecture Conversations (Day 8–14)
Before writing a line of code, I spent a week working through the design with Claude Code, leaning heavily on plan mode.
# Example from the design phase
claude --model claude-opus-4-6 "
Review this architecture for Next.js + Cloudflare Workers.
Requirements:
- Fetch data from App Store Connect API
- Unified dashboard for sales and reviews across multiple apps
- Stripe Pro monthly subscription ($5/month)
- Must scale to 10,000 users
Known constraints:
- App Store Connect API has rate limits
- Cloudflare Workers CPU limit is 10ms per request
"Two architectural pitfalls surfaced from that conversation.
Pitfall 1: Cloudflare Workers CPU limits
Aggregating App Store Connect data inside the Worker would exceed the CPU budget. Claude Code's recommendation: offload aggregation to a Cron Trigger and write results to KV. Making that call on Day 8 prevented a painful refactor later.
Pitfall 2: Stripe Webhook idempotency
A naive "charge complete → set KV flag" design breaks under Webhook retries. Claude Code flagged this before I'd even thought about it. Building idempotency keys into the design from the start avoided a class of bugs I've been burned by before.
4. Implementation — Model Switching and Token Discipline (Day 15–60)
This is the phase with the most direct impact on cost. Here's the decision framework I settled on.
Model assignment by task type
| Task | Model | Reason |
|---|---|---|
| Architecture / design decisions | claude-opus-4-6 | Requires complex reasoning |
| Feature implementation | claude-sonnet-4-6 | Best cost-to-quality ratio |
| Simple refactors | claude-haiku-4-5 | Fast, cheap |
| Bug fixes with known root cause | claude-haiku-4-5 | Direction already set |
In practice, I used Opus only for the morning design session. Everything else went to Sonnet and Haiku. That single change cut my monthly token cost by roughly 40%.
Session discipline
The most common Claude Code mistake I see — and made myself — is letting sessions run too long. When context bloats:
- The model starts proposing implementations that contradict earlier decisions
- Correction loops multiply, burning tokens
- It loses the thread of what changed and why
My fix was CLAUDE.md as a state ledger. At the end of each session, I wrote down what was decided. At the start of the next session, I loaded it in first.
<!-- CLAUDE.md state section example -->
## Current Implementation State (2026-03-15)
### Completed
- App Store Connect API wrapper (src/lib/asc.ts)
- Cloudflare KV caching strategy (5-minute TTL)
- Stripe Webhook idempotency key implementation
### Next session tasks
- Build dashboard UI components
- Add recharts for data visualization
- [ ] WARNING: recharts does not work in Cloudflare Workers (SSR is disabled)The warning notes are the most important part. Claude Code doesn't remember the last session, but the document does.
5. First Paying Customer (Day 30)
The first paid feature shipped on schedule. One design decision is worth sharing.
Reducing friction from free to paid
Claude Code's initial proposal for the onboarding flow asked for payment info immediately after signup. I pushed back and rewired it:
Sign up → 7-day full access trial → Day 8: paid features gated → Stripe Checkout
My reasoning was personal: services that ask for a card before I've seen any value lose me immediately. Let users experience the product first. The numbers backed this up — conversion from free to paid improved from 12% to 27% after adding the trial period.
The Stripe implementation was a one-line config change. The harder part was designing the email sequence — when to remind users the trial is ending, how to frame the ask — and that's where my back-and-forth with Claude Code was most iterative.
6. Production on Cloudflare (Day 60–90)
Three errors in production required Claude Code's help to diagnose. All were Cloudflare Workers-specific.
Error 1: Cannot perform I/O on behalf of a different request
claude "Analyze this stack trace from a Cloudflare Workers environment.
[paste stack trace]
I believe this is triggered when a KV operation is called from
a context that has already resolved. What's the fix?"Root cause: KV write without waitUntil(). Fix: five lines. I'd have spent a full day in the docs without Claude Code's immediate diagnosis.
Error 2: 62 MiB Worker bundle limit
As article count grew, the JSON data bundle started exceeding Cloudflare's traversal limit. Claude Code proposed a "Content Split Architecture" — separate metadata from HTML content, write content as individual files to public/, and fetch via the ASSETS binding at runtime. It's a meaningful architectural change, and having it explained alongside the code generation made the refactor manageable.
90-day cost and revenue snapshot
| Item | Amount |
|---|---|
| Claude Code token cost (90 days) | ~$300 |
| Cloudflare Workers (free plan) | $0 |
| Stripe fees (3.6% of revenue) | Variable |
| MRR at Day 90 | Not disclosed |
Token cost was heaviest in month one — about $130 — before I tightened the model-switching rules and CLAUDE.md discipline. Month two and three averaged around $85 each.
7. What the 90 Days Actually Taught Me
What worked
Spending real time on design. The two-week architecture phase with Claude Code meant the implementation phase had almost no major course corrections. I never had to tear out a foundational decision.
Documenting failures in CLAUDE.md. Writing down what went wrong between sessions meant I didn't repeat mistakes. Claude Code doesn't have memory across sessions — but the project document does.
What I'd do differently
Less perfectionism on UI. The first paying customers cared about whether the tool solved their problem, not whether the dashboard looked polished. I burned probably ten days on UI detail that didn't move conversion.
Shorter sessions. I once ran an eight-hour session that ended with Claude Code generating code that contradicted designs it had made four hours earlier. I rolled everything back. Now I break at two hours and update CLAUDE.md before stopping.
Ninety days is enough time to find out whether you can build a SaaS — and whether you can get someone to pay for it. Claude Code compressed the implementation timeline meaningfully. But "what to build" and "when to cut your losses" remain human decisions.
If you want to try this yourself, start with a 30-day challenge: the goal is to get one person to pay you for something before the month ends. That constraint forces the right prioritization. Claude Code is the best partner I've found for building toward it.