Lanciare un SaaS sulle directory con Claude Code: passo passo

Questa è una run completa di LaunchRepo con Claude Code, nell’ordine in cui avviene: il prompt che incolli, le domande che l’agente ti fa, la connessione al browser, la run pianificata e ogni stato che il tracker può registrare. Segue la release 1.9.0 del toolkit del 29 settembre 2026, e l’output del terminale mostrato più avanti viene da un’esecuzione reale degli script del toolkit del 30 settembre 2026. Se prima vuoi sapere se LaunchRepo si adatta davvero a Claude Code, la pagina su Claude Code lo spiega in una schermata. La guida Una run di lancio, dall’inizio alla fine descrive la stessa run per qualsiasi agente.

In breve: Claude Code fa il lavoro ripetitivo di leggere i playbook, compilare i moduli e scrivere il tracker. Tu porti quattro cose che solo una persona può portare: i dati del tuo prodotto, un Chrome con accesso già effettuato, la tua approvazione dei testi e i CAPTCHA e le richieste di verifica in due passaggi che le piattaforme riservano agli esseri umani. Ogni scheda resta una decisione della directory, e le revisioni gratuite richiedono spesso settimane, quindi l’obiettivo di una run è un insieme di invii onesti e confermati, non pagine istantanee.

La run in sintesi

Passo	Claude Code fa	Tu fai	Prova che ha funzionato
1. Prompt di avvio	Crea lo spazio di lavoro privato, avvia la dashboard	Incolli un prompt	Si apre un link 127.0.0.1
2. Onboarding	Ti intervista, compila product.json e copy.md	Rispondi, correggi, approvi	Un brief che firmeresti
3. Chrome	Configura Chrome DevTools MCP, esegue un test visibile	Attivi il debug remoto, approvi la richiesta di Chrome	Vedi la scheda muoversi
4. Permessi	Registra l’ambito una volta per prodotto	Decidi su badge, account, email	authorizations.json
5. La run	Pianifica 10 invii, una piattaforma alla volta	Risolvi i passaggi di consegna quando richiesto	Conteggio confermato nella dashboard
6. Tracker	Registra ogni esito con le prove	Confermi le schede pubbliche	Uno stato per piattaforma
7. Ripresa	Salva i progressi e le prossime date	Niente, fino alla sessione successiva	Il prossimo agente continua

Passo 0: cosa ti serve

• Il repository. Dopo l’acquisto ricevi un invito a un repository GitHub privato. Clonalo e apri la cartella in Claude Code.
• Git e Python 3.10 o più recente su Windows, macOS o Linux. Il tracker, la dashboard e gli script di supporto usano solo la libreria standard di Python, quindi non c’è nulla da installare. Su Windows usi py -3 ovunque la documentazione dica python3.
• Chrome, una versione LTS attuale di Node.js e npm per la connessione al browser. Il toolkit si collega tramite Chrome DevTools MCP, e la sua modalità --autoConnect richiede Chrome 144 o più recente.
• I dati del tuo prodotto: nome, URL, pubblico, funzionalità reali, prezzi come sono oggi, fase di lancio, screenshot autentici e un logo.

Il repository consiglia di usare Claude Code come CLI in un terminale invece dell’app desktop. È il flusso di lavoro documentato, e il prompt di avvio te lo ricorda una volta.

Passo 1: il prompt di avvio

Incolla il prompt di START.md esattamente com’è scritto:

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.

Il prompt resta in inglese; Claude Code risponde nella tua lingua dopo aver letto le istruzioni. Crea uno spazio di lavoro privato accanto al checkout, così i tuoi prodotti e le tue credenziali non finiscono mai nel repository di distribuzione. Poi avvia la dashboard locale e risponde con un link 127.0.0.1. Da qui in poi tutto può avvenire in quella scheda o nella chat, perché i moduli della dashboard scrivono gli stessi file che legge l’agente.

Preferisci dare un’occhiata prima di impegnarti? python3 scripts/dashboard.py --demo apre uno spazio di lavoro usa e getta con un prodotto di fantasia.

Passo 2: l’intervista di onboarding

ONBOARDING.md ha sette fasi, e l’agente le conduce una alla volta. Legge i file esistenti prima di chiedere qualsiasi cosa, quindi una seconda sessione non ripete mai la prima.

A che punto siamo. L’agente ti chiede nome e URL del tuo primo prodotto e la cartella con il suo codice o i tuoi appunti, ed esamina queste fonti prima di fare altre domande. Determina anche il tuo sistema operativo e quali strumenti browser può davvero richiamare. Qui le istruzioni sono esplicite: un terminale da solo non è controllo del browser, e l’agente non deve dichiarare strumenti che la sessione non ha.

Una casa privata. Claude Code ti aiuta a creare un tuo remote privato per lo spazio di lavoro e ti spiega che i dati di accesso salvati lì sono leggibili da chiunque abbia accesso a quel repository, cronologia compresa. Scegli tu: credenziali nello spazio di lavoro, riferimenti a un gestore di segreti o niente. Chiede anche, una volta sola, se i problemi possono essere segnalati ai maintainer di LaunchRepo come issue su GitHub, senza segreti e indirizzi email. Nessuna risposta significa no.

Il prodotto. Uno script crea la cartella del prodotto, poi l’agente compila il file di contesto del prodotto product.json con le tue risposte e avvia il laboratorio dei testi, che produce copy.md con varianti per diversi limiti di campo. Ciò che non si sa resta vuoto. Le funzionalità pianificate non diventano mai funzionalità disponibili.

Questa fase fissa anche la tua data minima di lancio. Molte directory gratuite mettono gli invii in coda di revisione per settimane, quindi l’agente chiede se c’è una data prima della quale nulla deve andare online, e il tracker poi rifiuta qualsiasi record scheduled precedente.

Identità. identity.json contiene il nome pubblico, l’email di accesso e i dati dell’organizzazione che autorizzi. Prima che qualcosa arrivi in una scheda, l’agente esegue il briefing di rappresentanza: tre brevi frasi di esempio su di te, mostrate parola per parola perché tu le corregga.

Passo 3: collegare Chrome e la tua casella di posta

È il passo che fa funzionare tutto il resto. L’agente ha bisogno di un browser che tu possa vedere e sorvegliare, e BROWSER-SETUP.md supporta esattamente un solo trasporto: Chrome DevTools MCP tramite il debug remoto di Chrome. La guida Collega il tuo coding agent al tuo Chrome descrive entrambe le strade.

Strada A: il tuo Chrome esistente. Controlla chrome://version (144 o più recente), apri chrome://inspect/#remote-debugging nel Chrome che vuoi far usare all’agente e attiva lì il debug remoto. Poi registra il server in Claude Code con claude mcp add; la guida ai client di Chrome DevTools MCP riporta la riga esatta, e il repository ci aggiunge --autoConnect. La documentazione MCP di Claude Code spiega gli ambiti, se vuoi il server solo per questo progetto.

Strada B: un profilo dedicato. Se il controllo del debug remoto manca o la connessione automatica fallisce, Chrome si avvia con una propria cartella di profilo dentro lo spazio di lavoro e una porta di debug locale, e la configurazione usa invece --browserUrl. In quella finestra accedi una volta sola. La porta non esce mai da localhost, e i cookie non vengono mai copiati.

Poi arriva il test visibile. Apri una scheda vuota nel profilo previsto, l’agente la porta su https://example.com/ e legge il titolo “Example Domain”, e tu confermi che si è mossa proprio quella scheda. Questo prova il controllo di quell’unica scheda tramite il Chrome DevTools Protocol, niente di più; un processo MCP in esecuzione o una schermata OAuth completata non sono una prova. Su macOS una connessione del genere di norma non richiede i permessi di Accessibilità, Automazione o Registrazione schermo. Dopo il tuo primo vero accesso, l’agente controlla nel menu dell’account che l’identità sia quella giusta e conferma l’accesso alla casella di posta, perché la maggior parte delle registrazioni si conclude con un’email di verifica. Inoltrare i codici a mano è un’alternativa supportata, che il tracker registra come passaggio di consegna a una persona.

Dopo una riconnessione Chrome può mostrare di nuovo la sua richiesta di connessione. È un controllo di sicurezza, e all’agente è detto di non promettere mai di eliminarlo né di aggirare i CAPTCHA.

Passo 4: i permessi, una volta per prodotto

Prima di inviare qualsiasi cosa, l’agente legge WEBSITE-AND-EMAIL.md e ti fa alcune domande che non ripeterà: dove si trova il codice del tuo sito, come viene pubblicato, quale branch è la produzione e se può aggiungere al footer i badge della directory richiesti, fare commit e ripubblicare. Chiede anche se sono consentite registrazioni gratuite, invii finali gratuiti e le relative azioni sulle email di verifica. Risposte, data e ambito esatto finiscono in authorizations.json. La spesa resta a zero, e ogni upsell a pagamento viene rifiutato.

Dire no ai badge va benissimo: esclude soltanto le directory che ne richiedono uno. Ogni prodotto ha la sua autorizzazione, quindi un sì per un prodotto non si trasferisce mai al successivo.

Passo 5: pianificare la run e guardare il contatore

Ora doctor.py separa la configurazione mancante dai permessi che hai negato, e l’agente apre il pianificatore della run. I valori predefiniti sono voluti: 10 nuovi invii, un solo worker del browser, 150 minuti attivi in totale e 15 per piattaforma. In coda entrano solo i percorsi gratuiti pronti: aggiornati, documentati, funzionanti e gratuiti senza condizioni. I percorsi con condizioni vengono mostrati a parte con i loro prerequisiti. Se i percorsi adatti pronti sono meno del tuo obiettivo, l’agente ti propone la run più piccola e veritiera. Dove Claude Code supporta /goal, l’obiettivo generato viene proposto per quel comando; altrimenti lo stesso testo funziona come prompt normale.

Ecco come appare la run nel terminale. Il 30 settembre 2026 abbiamo creato uno spazio di lavoro nuovo e un prodotto vuoto con gli script del toolkit ed eseguito i comandi documentati. Le righe qui sotto sono copiate da quella esecuzione, ridotte ai campi rilevanti:

$ 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,

Due cose meritano attenzione. Il tracker si è rifiutato di chiamare live una pagina di ringraziamento: gli stati pubblici richiedono un URL verificato e la tua conferma esplicita. E il record onesto, un invio in revisione, ha spostato il contatore da 10 rimanenti a 9. Le conferme di ricezione contano per l’obiettivo; non devi aspettare settimane la pubblicazione per sapere che la tua run è andata avanti.

Aspettati passaggi di consegna lungo la strada. Quando compare un CAPTCHA, una richiesta di verifica in due passaggi o uno stato dell’account poco chiaro, l’agente tiene aperta la bozza, registra prepared_needs_human con esattamente un’azione per te, e la dashboard la elenca sotto “serve il tuo intervento”. La risolvi nella stessa finestra, e la run continua.

Passo 6: cosa significano gli stati del tracker

Ogni esito passa da record.py a submissions.json, e la dashboard mostra gli stessi undici stati. Ognuno richiede un’osservazione minima, quindi un risultato non può essere gonfiato. Solo quattro spostano il contatore della run:

Stato	Osservazione minima	Conta per l’obiettivo della run
draft	Lavoro preparato, invio finale non confermato	No
prepared_needs_human	Un unico ostacolo preciso che solo tu puoi risolvere	No
submitted_pending_review	La piattaforma ha confermato la ricezione; moderazione in sospeso	Sì
queued	La piattaforma ha confermato una posizione in coda	Sì
scheduled	Una data confermata uguale o successiva alla tua data minima di lancio	Sì
live	URL pubblico verificato più la tua conferma	Sì
already_listed	Una scheda pubblica già esistente, stessa prova di live	No
blocked	Requisiti, limite dell’account o un dato mancante	No
deferred_paid	L’unico percorso utilizzabile costa denaro; nulla acquistato	No
not_a_fit	Pubblico o criteri della scheda non corrispondono	No
unavailable	Il percorso al momento non è utilizzabile	No

Ogni piattaforma conta una volta per run, per quanto spesso il suo stato cambi in seguito. La voce Listing status spiega il vocabolario, e la guida Tracciare gli invii alle directory senza contarli due volte copre i casi limite, come una casella di un partner che promette un secondo sito.

Passo 7: lasciare uno spazio di lavoro riprendibile

A fine sessione l’agente spunta le voci dell’onboarding solo per i controlli che ha davvero osservato, scrive le prove non sensibili e i passi aperti in SESSION.md, inserisce le prossime date in FOLLOW-UP.md ed esegue un controllo di privacy su git prima del push sul tuo remote privato. La sessione successiva, tua o di un altro agente, legge prima il tracker: passaggi di consegna, lanci programmati da verificare, poi le revisioni in attesa la cui finestra è passata. Ricontrolla i record esistenti invece di inviare due volte.

Questo è il vero vantaggio. Il tuo secondo prodotto riusa la configurazione del browser, l’identità, lo schema dei permessi e i 299 playbook attivi dell’istantanea del catalogo del 24 settembre 2026; solo product.json e i testi sono nuovi.

Dove andare da qui

Come funziona mostra i passi con il video del founder. Il catalogo delle directory ti permette di leggere alcune guide sul campo pubbliche prima di decidere, e il registro delle modifiche elenca ogni release del toolkit. Vuoi che Claude Code scriva anche i testi di marketing? Confronta le migliori skill marketing Claude Code. Gli altri agenti sono trattati nelle pagine sugli agenti. Il repository si acquista una volta sola nella pagina dei prezzi.

Domande frequenti

Claude Code può inviare da solo il mio SaaS alle directory?

In gran parte sì. Con il repository, un Chrome collegato e i tuoi permessi, Claude Code legge ogni playbook, compila il modulo e registra l’esito. Tu approvi i testi, confermi le schede pubbliche e risolvi CAPTCHA o richieste di verifica in due passaggi quando la run si ferma per te.

Mi serve la CLI di Claude Code o va bene anche l’app desktop?

Il repository consiglia la CLI in un terminale per i risultati migliori, e il prompt di avvio lo dice. L’app desktop non è bloccata: se resti lì, l’agente prosegue il lavoro autorizzato e i progressi salvati restano intatti.

Quanto dura la prima run?

Il pianificatore prevede 150 minuti attivi per 10 piattaforme, 15 per piattaforma. Sono limiti di coordinamento che mettono in pausa la run quando vengono raggiunti, non una promessa di velocità, e il tempo che dedichi ai passaggi di consegna dipende dalle piattaforme.

Cosa succede quando una directory mostra un CAPTCHA?

L’agente si ferma davanti alla verifica, tiene aperta la bozza e registra prepared_needs_human con un’unica azione precisa per te. La risolvi nella stessa finestra, e la run riprende da lì.

Lo stesso procedimento funziona con Codex o Cursor?

Sì. I file, il tracker e la configurazione del browser sono gli stessi per ogni agente che può leggere il repository e usare Chrome DevTools MCP. Le pagine sugli agenti indicano cosa cambia per ciascuno strumento.

Fonti: START.md, ONBOARDING.md, BROWSER-SETUP.md, WEBSITE-AND-EMAIL.md, RUNBOOK.md e CHANGELOG.md nel toolkit di LaunchRepo (release 1.9.0, 29 settembre 2026); il prompt di avvio citato alla lettera; un’esecuzione di run.py e record.py del 30 settembre 2026; il riferimento di configurazione di Chrome DevTools MCP (Chrome 144 o più recente per --autoConnect), verificato il 30 settembre 2026. Non vengono indicati dati su tempi o risultati tra i clienti, perché non ne sono stati misurati.