CLAUDE LABJP
FORK — Claude Code 2.1.212 changes what /fork does: it copies your conversation into a new background session with its own row in claude agents, so you can keep working. The old in-session subagent is now /subtaskLIMITS — WebSearch calls are now capped at 200 per session by default, and subagent spawns get the same 200 ceiling, so a runaway search or delegation loop stops on its ownMCPBG — MCP tool calls running past two minutes now move to the background automatically, keeping the session usable. Tune the threshold with CLAUDE_CODE_MCP_AUTO_BACKGROUND_MSPLANFIX — Fixed plan mode auto-running file-modifying Bash commands such as touch and rm without a permission prompt or an SDK canUseTool callbackSONNET5 — Claude Sonnet 5 is running on introductory pricing of $2 per million input tokens and $10 per million output. After August 31 it moves to $3 and $15IPO — Bankers are reportedly lining up investor meetings for Anthropic ahead of a possible public listing as soon as OctoberFORK — Claude Code 2.1.212 changes what /fork does: it copies your conversation into a new background session with its own row in claude agents, so you can keep working. The old in-session subagent is now /subtaskLIMITS — WebSearch calls are now capped at 200 per session by default, and subagent spawns get the same 200 ceiling, so a runaway search or delegation loop stops on its ownMCPBG — MCP tool calls running past two minutes now move to the background automatically, keeping the session usable. Tune the threshold with CLAUDE_CODE_MCP_AUTO_BACKGROUND_MSPLANFIX — Fixed plan mode auto-running file-modifying Bash commands such as touch and rm without a permission prompt or an SDK canUseTool callbackSONNET5 — Claude Sonnet 5 is running on introductory pricing of $2 per million input tokens and $10 per million output. After August 31 it moves to $3 and $15IPO — Bankers are reportedly lining up investor meetings for Anthropic ahead of a possible public listing as soon as October
Articles/Claude Code
Claude Code/2026-04-21Advanced

The 12-Week Roadmap from Zero to a Monetized Claude Code Product

A week-by-week roadmap for indie developers starting from a single idea and reaching a product with paying users in 12 weeks, built around Claude Code. Includes the exact prompts I use and the mistakes I ran into along the way.

Claude Code196Indie Dev22Monetization9RoadmapLaunch

Search for "indie monetization roadmap" and you will find four-step outlines: come up with an idea, build an MVP, launch, do marketing. If you have actually tried to ship something, you know that level of granularity is useless. It tells you nothing about what to do on Monday morning.

This article lays out a week-by-week roadmap — from a single idea to a product that actually has paying users — over twelve weeks. It is based on how I have shipped indie apps since 2014, updated with the way I run new projects on Claude Code in 2026. For each week I include what to build, what to prompt Claude Code with, and the mistake that is most likely to bite you. By the end, you should never be unsure what to do next Monday.

The shape of the 12 weeks

Twelve weeks divide cleanly into four phases.

Phase 1 (Weeks 1-3): Scope and validate. This is where you decide what is worth building. Most indie developers try to finish this in three days and fail. Three weeks is the right budget.

Phase 2 (Weeks 4-7): Build. This is where Claude Code earns its keep. You go from no product to a usable MVP.

Phase 3 (Weeks 8-9): Prep and launch. Payments, legal copy, SEO, and onboarding all happen here. It feels less exciting than building, but skipping it guarantees zero revenue.

Phase 4 (Weeks 10-12): Monetize and improve. You learn from real users and iterate. What you learn here determines what your next 12 weeks look like.

Each phase has a concrete "what should be true right now" checkpoint so you can tell whether you are on track.

Phase 1: Scope and validate (Weeks 1-3)

Week 1: Find the right problem

Your goal this week is to be able to state the problem you are solving in a single sentence. Without that, Claude Code will sprint in the wrong direction no matter how fast it moves.

The exercise I actually run is to list ten moments in the past month when I hit the same friction three or more times. A recurring annoyance is almost always shared by others, and those ten candidates become your raw pool. Narrow them down to the ones you could plausibly solve alone.

This week's Claude Code prompt is for analysis, not code:

Evaluate the 10 frictions I listed below:
1. ...
2. ...

For each item, score:
- Probability that other indie developers share this pain (1-5)
- Difficulty of solving it alone (1-5, lower = easier)
- Confidence that no adequate solution exists (1-5)

Rank them by total score and sketch the target user for the top three.

Claude Code is excellent at narrowing down who hurts from what. Use it to sharpen your target before you write any code.

Week 2: Competitors and your wedge

Week 2 is research-only. For your top three candidates, survey ten existing competitors each. List what is missing, what is overpriced, and what is awkward to use.

Indie developers can realistically compete on a handful of dimensions: price, speed, deep fit with a specific use case, or sheer niche-ness. Large incumbents cannot afford to serve "this profession, in this language, with this workflow." A single founder can. That is your wedge.

By the end of the week, decide three things: the product name, a one-person target user (an actual imagined person, not a demographic), and your wedge. Every downstream decision becomes easier once these are written down.

Week 3: Stack and project skeleton

Week 3 is when Claude Code finally starts writing code — but not feature code. The target is a complete CLAUDE.md and a repository skeleton.

If you go with the stack I recommend (Next.js 16, Cloudflare Workers, Stripe, Supabase, Auth.js), prompt Claude Code with:

Product name: {name}
Target user: {one-sentence persona}
Wedge: {price / speed / niche / use case}

Create:
1. CLAUDE.md — project summary, stack, constraints, coding conventions
2. Repository skeleton — Next.js 16 App Router scaffold
3. .env.example — all required environment variables with comments
4. README.md — setup and dev-loop instructions

If npm run dev runs locally by the end of the week, Week 3 is done. No features yet, and that is fine.

Phase 2: Build (Weeks 4-7)

Week 4: Prototype the core loop

Ship one feature, end to end. Resist the urge to add a second one.

The prompting pattern I lean on is three minimal user stories:

Implement the smallest code that satisfies these stories:
1. The user can try {feature} (no auth, free)
2. The user can save the result (auth required)
3. The user can list saved results

Only focus on the above this week. Payments, i18n, and SEO come later.

Wiring in Supabase auth and getting "sign in → use feature → save → list" running locally is the bar for Week 4.

Week 5: Flow and visual polish

Week 5 is where a working prototype becomes a product anyone else can understand.

When asking Claude Code to handle visual design, I pass three reference URLs: "header like this," "palette like this," "typography like this." Claude Code is strong, but vague prompts like "make it look cool" produce generic output. Specific references produce specific output.

By the end of the week, hand the product to one person who is not you — a friend, a family member, one SNS follower — and watch whether they can reach the core feature without getting stuck. Every hesitation is a flow bug.

Week 6: Paywall design

Week 6 is when you draw the line between free and paid. This is the single hardest decision in indie monetization. Too much free, no revenue. Too little, no users.

My rough 2026 rule of thumb for indie products:

  • Subscription SaaS: 2-5 free uses per day, paywall above that
  • One-time purchase: free core, paid advanced features or exports
  • Content product: latest content paid, older than 30 days free

Pick the shape that fits your product, then have Claude Code implement the limit logic. Counting per-user daily usage in KV or Supabase is the standard pattern.

Week 7: Payments and your own dashboard

This is Stripe Checkout week. Use the price_data + product_data pattern from the companion stack article.

The often-skipped step is building your own admin dashboard. Show new users, successful payments, failed payments, and MRR on one screen, pulling from Supabase. Claude Code can produce this in a few hours.

Without an admin dashboard, you will open the Stripe dashboard every time you want to know whether anyone bought anything. That friction slows your improvement loop down, and a slow loop after launch is the main reason indie products stall.

Phase 3: Prep and launch (Weeks 8-9)

Week 8: Legal, SEO, and OGP

Three items are mandatory before launch if you ship to Japan with Stripe: the Act on Specified Commercial Transactions disclosure, a privacy policy, and terms of service. Non-Japan markets have analogous requirements.

You can have Claude Code draft these from templates, but the final read must be yours. Pay special attention to refund and cancellation policies — they define how future disputes resolve.

For SEO, aim for the minimum this week: per-page metadata generated through generateMetadata, and an OGP image for every page. A generic OGP is fine — what is not fine is no OGP, because SNS shares then fall flat and you lose your earliest inbound.

Week 9: Private beta, then a soft launch

The first half of Week 9 is a private beta with 5-10 people you know. The second half is a soft launch on SNS.

The beta's most important job is to confirm payments complete end to end. On one of my own launches, I forgot to distinguish between tip and premium metadata at the Stripe Checkout layer, and tip purchases accidentally unlocked every premium article. You cannot catch bugs like this without running real charges. Do at least one real payment per plan type.

During the soft launch, polish the screens a paying customer sees first — thank-you page, receipt instructions, and a quick "how to use it now" card. Bad first impressions kill referrals before they happen.

Phase 4: Monetize and improve (Weeks 10-12)

Week 10: Your first 100 paying users

By launch week, you want at least three inbound paths live. In my own experience, the paths that actually delivered users early were:

  • Announcements on my own SNS (Instagram, X, Threads)
  • Funnels from my existing sites or apps
  • Posts in places where the target user already hangs out (Reddit, Discord, note, Zenn)

Do not count on "Claude Code writes blog posts and SEO picks us up." Search ranking needs three months minimum to stabilize, which is outside our 12-week horizon. For the first 100 users, you reach out to people actively.

Week 11: Data-driven improvements

Once some paying users exist, Week 11 is analysis and iteration. Three numbers matter: landing-page bounce rate, free-to-paid conversion rate, and paid retention.

Have Claude Code write the Supabase queries:

Write SQL against these tables for the last 7 days:
- visitors: landing page visits
- signups: free sign-ups
- purchases: paid conversions
- churn_7d: users who churned within 7 days of purchase

Looking at these numbers every day is what separates a product that improves from one that stalls.

Week 12: Design the next 12 weeks

The final week is not about the current product. It is about designing the next 12 weeks.

In my experience, products finished by Week 12 usually ship fewer than half of the features I originally imagined. The other half turn out to be unnecessary by the time I talk to real users. This is the healthy state of indie development. Do not add what was missing — double down on whatever Weeks 10-11 revealed as the most loved part, and design the next 12 weeks around that.

Three failure modes I see repeatedly

Before I close, three failure modes worth watching for.

Feature creep. Claude Code makes it tempting to add just-one-more thing. But more features mean more decisions for the user. Anything outside the three user stories you fixed in Week 4 should wait until after Week 12. This is a discipline problem, not a tool problem.

Delaying launch. Weeks 8-9 are designed to push you out the door. Aiming for perfection means you never launch. A rough product with paying users beats a polished product that reaches no one. Always.

Scattering inbound from day one. I said three paths in Week 10, but for the first week you want to concentrate on the single highest-response channel. In my case, SNS from my own account has always moved the needle first. SEO and Reddit follow with a lag.

What to do on Monday morning

The real payoff of this roadmap is not the 12-week arc — it is knowing what to do next Monday.

If you are starting at Phase 1 Week 1 today, your task for Monday is to list ten frictions you hit three or more times in the past month. Pen and paper works better than a prompt here. Write before you ask Claude Code anything.

Twelve weeks from now, you will be an indie developer with a product that real people pay for. That is where being an indie developer actually begins.

Share

Thank You for Reading

Claude Lab is ad-free, supported entirely by members like you. We publish practical guides daily with implementation code, benchmarks, and production-ready patterns. If you've found it useful, we'd love to have you on board.

  • Copy-paste ready implementation code
  • New advanced guides published daily
  • $5/mo or $10 for lifetime access
View Membership →

If you found this article helpful, a small tip ($1.50) would mean a lot to us. Your support helps keep this site ad-free and covers server and hosting costs.

Related Articles

Claude Code2026-04-26
Designing Pricing for Indie Projects with Claude Code — Shorten the Lead Time to Your First Revenue
When indie projects fail to earn, the gap is rarely technical — it's pricing design and lead time. Here's a practical mindset for using Claude Code to ship the smallest revenue-ready MVP and reach your first paying customer faster.
Claude Code2026-06-19
An Article My Gate Rejected Got Published — The Cost of Chaining the Quality Gate and git push in One Call
In an unattended publishing pipeline, an article my quality gate had rejected went live anyway. The cause was chaining the gate and git push into a single shell call. Here is how the exit code gets swallowed, and a two-phase publish-marker design that refuses to push until every gate has demonstrably passed.
Claude Code2026-06-17
When an Announced Billing Change Is Withdrawn at the Last Minute, Change No Code
A billing change that was supposed to take effect was withdrawn on the day. To survive announce, apply, and revert without touching code, I keep platform behavior behind a single flag and project the monthly delta from real logs.
📚RECOMMENDED BOOKS
Build a Large Language Model (From Scratch)
Sebastian Raschka
LLM Dev
Prompt Engineering for LLMs
Berryman & Ziegler
Prompting
AI Engineering
Chip Huyen
AI Eng
* Contains affiliate links
See all →