Launch a SaaS on directories with Claude Code: walkthrough

This is one complete LaunchRepo run with Claude Code, in the order it happens: the prompt you paste, the questions the agent asks, the browser connection, the planned run and every state the tracker can record. It follows toolkit release 1.9.0 of 29 September 2026, and the terminal output shown further down comes from a real run of the toolkit’s own scripts on 30 September 2026. If you first want to know whether LaunchRepo fits Claude Code at all, the Claude Code page answers that on one screen. The launch run guide describes the same run for any agent.

The short version: Claude Code does the repetitive work of reading playbooks, filling forms and writing the tracker. You bring four things only a person can bring: your product facts, a signed-in Chrome, your approval of the copy, and the CAPTCHAs and two-factor prompts that platforms reserve for humans. Every listing is still the directory’s decision, and free reviews often take weeks, so the goal of a run is a set of honest, confirmed submissions rather than instant pages.

The run at a glance

Step	Claude Code does	You do	Proof it worked
1. Start prompt	Creates the private workspace, starts the dashboard	Paste one prompt	A 127.0.0.1 link opens
2. Onboarding	Interviews you, fills product.json and copy.md	Answer, correct, approve	A brief you would sign
3. Chrome	Configures Chrome DevTools MCP, runs a visible test	Enable remote debugging, approve Chrome’s prompt	You watch the tab move
4. Permissions	Records the scope once per product	Decide badges, accounts, email	authorizations.json
5. The run	Plans 10 submissions, one platform at a time	Solve handoffs when asked	Confirmed count in the dashboard
6. Tracker	Records each outcome with evidence	Confirm public listings	One state per platform
7. Resume	Saves progress and next dates	Nothing, until the next session	The next agent continues

Step 0: what you need

• The repository. After purchase you get an invitation to a private GitHub repository. Clone it and open the folder in Claude Code.
• Git and Python 3.10 or newer on Windows, macOS or Linux. The tracker, the dashboard and the helper scripts use only Python’s standard library, so there is nothing to install. On Windows you use py -3 wherever the docs say python3.
• Chrome, a current Node.js LTS and npm for the browser connection. The toolkit connects through Chrome DevTools MCP, and its --autoConnect mode needs Chrome 144 or newer.
• Your product facts: name, URL, audience, real features, pricing as it is today, launch stage, genuine screenshots and a logo.

The repository recommends running Claude Code as the CLI in a terminal rather than the desktop app. That is the documented workflow, and the start prompt reminds you of it once.

Step 1: the start prompt

Paste the prompt from START.md exactly as written:

Recommend Claude Code CLI or Codex CLI in a terminal instead of the desktop apps for best results. If session metadata confirms desktop hosting, explicitly advise me to switch to the CLI and resume this same private workspace. Do not infer the host from a CLI engine version alone. Read AGENTS.md, then follow “Start the dashboard for the owner”. Create my private workspace if I do not have one yet, start the dashboard, and give me the link. Then lead ONBOARDING.md one phase at a time. Reuse recorded permissions instead of asking again unless their scope is missing or conflicting. Actually test my visible existing Chrome profile and intended identity as BROWSER-SETUP.md requires; use the OS fallback if needed. Use one platform/browser worker by default. Build the normal run only from suitable free-ready routes, keep research separate, and preserve any draft that needs one exact human CAPTCHA/2FA action. Never claim browser control bypasses or reduces those challenges.

The prompt stays in English; Claude Code answers in your language once it has read the instructions. It creates a private workspace next to the checkout, so your products and credentials never live in the delivery repository. Then it starts the local dashboard and replies with a 127.0.0.1 link. Everything after this can happen in that tab or in the chat, because the dashboard forms write the same files the agent reads.

Prefer to look before you commit? python3 scripts/dashboard.py --demo serves a throwaway workspace with a fictional product.

Step 2: the onboarding interview

ONBOARDING.md has seven phases, and the agent leads them one at a time. It reads existing files before asking anything, so a second session never repeats the first.

Where we are. The agent asks for your first product’s name, URL and the folder with its code or notes, and inspects those sources before follow-up questions. It also determines your OS and which browser tools it can actually call. The instructions are blunt here: a terminal alone is not browser control, and the agent must not claim tools the session does not have.

A private home. Claude Code helps you create your own private remote for the workspace and explains that any login details stored there are readable by everyone with access to that repository, including its history. You choose: credentials in the workspace, references to a secret manager, or nothing. It also asks once whether problems may be reported to the LaunchRepo maintainers as GitHub issues, with secrets and email addresses removed. No answer means no.

The product. A script creates the product folder, then the agent fills the product context file product.json from your answers and runs the copy workshop, which produces copy.md with variants for different field limits. Unknowns stay empty. Planned features never become available ones.

This phase also sets your earliest launch date. Many free-tier directories queue submissions for review for weeks, so the agent asks whether there is a date before which nothing should go live, and the tracker then refuses any scheduled record before it.

Identity. identity.json holds the public name, the sign-in email and the organisation facts you allow. Before any of it reaches a listing, the agent runs the representation briefing: three short sample sentences about you, shown verbatim for correction.

Step 3: connecting Chrome and your mailbox

This is the step that makes everything else work. The agent needs a browser you can see and supervise, and BROWSER-SETUP.md supports exactly one transport: Chrome DevTools MCP over Chrome remote debugging. The Chrome connection guide walks through both routes.

Route A: your existing Chrome. Check chrome://version (144 or newer), open chrome://inspect/#remote-debugging in the Chrome you want the agent to use and enable remote debugging there. Then register the server in Claude Code with claude mcp add; the Chrome DevTools MCP client guide has the exact line, and the repository adds --autoConnect to it. Claude Code’s own MCP documentation explains scopes if you want the server for this project only.

Route B: a dedicated profile. If the remote-debugging control is missing or auto-connect fails, Chrome starts with its own profile directory inside the workspace and a local debugging port, and the configuration uses --browserUrl instead. You sign in once in that window. The port never leaves localhost, and cookies are never copied.

Then comes the visible test. You open a blank tab in the intended profile, the agent navigates it to https://example.com/ and reads the “Example Domain” heading, and you confirm that the same tab moved. That proves control of this one tab over the Chrome DevTools Protocol, nothing more; a running MCP process or a completed OAuth screen is not proof. On macOS a connection like this normally needs no Accessibility, Automation or Screen Recording permission. After your first real sign-in, the agent checks the account menu for the right identity and confirms mailbox access, because verification emails finish most registrations. Forwarding codes by hand is a supported fallback that the tracker records as a human handoff.

Chrome may show its connection prompt again after a reconnect. That is a security control, and the agent is told never to promise it away or to bypass CAPTCHAs.

Step 4: permissions, once per product

Before anything is submitted, the agent reads WEBSITE-AND-EMAIL.md and asks a handful of questions it will not ask again: where your website code lives, how it deploys, which branch is production, and whether it may add required directory badges to your footer, commit and redeploy. It also asks whether free registrations, free final submissions and the matching verification-email actions are allowed. Answers, date and exact scope go into authorizations.json. Spending stays at zero, and every paid upsell is declined.

Saying no to badges is fine: it only rules out the directories that require one. Each product gets its own grant, so a yes for one product never carries over to the next.

Step 5: plan the run and watch the counter

Now doctor.py separates missing setup from permissions you declined, and the agent opens the run planner. The defaults are deliberate: 10 new submissions, one browser worker, 150 active minutes in total and 15 per platform. Only free-ready routes enter the queue: fresh, evidenced, working and free without conditions. Routes with conditions are shown separately with their prerequisites. If fewer suitable routes are ready than your target, the agent offers the smaller, truthful run. Where Claude Code supports /goal, the generated objective is offered for it; otherwise the same text works as a normal prompt.

Here is what the run looks like in the terminal. We created a fresh workspace and a blank product with the toolkit’s scripts on 30 September 2026 and ran the documented commands. The lines below are copied from that run, shortened to the relevant fields:

$ python3 scripts/run.py --project projects/my-product start --target 10 --total-minutes 150 --platform-minutes 15
  "target": 10,
  "parallel": 1,
  "remaining": 10,
$ python3 scripts/run.py --project projects/my-product claim pitchwall --worker worker-1 --window window-1
$ python3 scripts/record.py --project projects/my-product pitchwall live --worker worker-1 --note 'Thank-you page shown' --next-action 'Open the public listing'
Tracker rejected input: Public states require a reviewed URL and --confirmed-public
$ python3 scripts/record.py --project projects/my-product pitchwall submitted_pending_review --worker worker-1 --note 'Dashboard confirms Under Review' --next-action 'Recheck after the stated review window'
Recorded pitchwall: submitted_pending_review
$ python3 scripts/run.py --project projects/my-product status
  "completed_count": 1,
  "remaining": 9,

Two things are worth seeing. The tracker refused to call a thank-you page live: public states need a reviewed URL and your explicit confirmation. And the honest record, a submission under review, moved the counter from 10 remaining to 9. Receipts count toward the target; you do not have to wait weeks for publication to know your run made progress.

Expect handoffs along the way. When a CAPTCHA, a two-factor prompt or an unclear account state appears, the agent keeps the draft open, records prepared_needs_human with exactly one action for you, and the dashboard lists it under “needs you”. You solve it in the same window, and the run continues.

Step 6: what the tracker states mean

Every outcome goes through record.py into submissions.json, and the dashboard shows the same eleven states. Each one requires a minimum observation, so a result cannot be inflated. Only four of them move the run counter:

State	Minimum observation	Counts toward the run target
draft	Work prepared, final submission not confirmed	No
prepared_needs_human	One specific blocker only you can resolve	No
submitted_pending_review	The platform confirmed receipt; moderation pending	Yes
queued	The platform confirmed a queue position	Yes
scheduled	A confirmed date on or after your earliest launch date	Yes
live	Reviewed public URL plus your confirmation	Yes
already_listed	An existing public listing, same proof as live	No
blocked	Eligibility, account limit or a missing fact	No
deferred_paid	The only usable route costs money; nothing bought	No
not_a_fit	Audience or listing criteria do not match	No
unavailable	The route cannot be used right now	No

Each platform counts once per run, however often its state changes later. The listing status entry explains the vocabulary, and the status tracking guide covers edge cases such as a partner checkbox that promises a second site.

Step 7: leaving a resumable workspace

At the end of a session the agent ticks onboarding items only for checks it actually observed, writes non-sensitive evidence and open steps to SESSION.md, puts the next dates into FOLLOW-UP.md and runs a git privacy check before pushing to your private remote. The next session, yours or another agent’s, reads the tracker first: handoffs, scheduled launches due for a check, then pending reviews whose window has passed. It rechecks existing records instead of submitting twice.

That is the real payoff. Your second product reuses the browser setup, the identity, the permission pattern and the 299 active playbooks of the catalog snapshot from 24 September 2026; only product.json and the copy are new.

Where to go from here

How it works shows the steps with the founder video. The directory catalog lets you read a few public field guides before you decide, and the changelog lists every toolkit release. Want Claude Code to write marketing copy as well? Compare the Claude Code marketing skills. Other agents are covered on the agent pages. The repository itself is bought once on the pricing page.

Frequently asked questions

Can Claude Code submit my SaaS to directories on its own?

Largely, yes. With the repository, a connected Chrome and your permissions, Claude Code reads each playbook, fills the form and records the outcome. You approve the copy, confirm public listings and solve CAPTCHAs or two-factor prompts when the run pauses for you.

Do I need the Claude Code CLI, or does the desktop app work?

The repository recommends the CLI in a terminal for best results, and the start prompt says so. The desktop app is not blocked: if you stay there, the agent continues the authorised work and saved progress stays intact.

How long does the first run take?

The planner budgets 150 active minutes for 10 platforms, 15 per platform. These are coordination limits that pause the run when reached, not a speed promise, and the time you spend on handoffs depends on the platforms.

What happens when a directory shows a CAPTCHA?

The agent stops at the challenge, keeps the draft open and records prepared_needs_human with one exact action for you. You solve it in the same window, and the run continues from there.

Does the same walkthrough work with Codex or Cursor?

Yes. The files, the tracker and the browser setup are the same for every agent that can read the repository and use Chrome DevTools MCP. The agent pages list what differs for each tool.

Sources: START.md, ONBOARDING.md, BROWSER-SETUP.md, WEBSITE-AND-EMAIL.md, RUNBOOK.md and CHANGELOG.md in the LaunchRepo toolkit (release 1.9.0, 29 September 2026); the start prompt quoted verbatim; a run of run.py and record.py on 30 September 2026; the Chrome DevTools MCP configuration reference (Chrome 144 or newer for --autoConnect), checked on 30 September 2026. No timing or outcome figures across customers are given, because none were measured.