Lanzar un SaaS en directorios con Claude Code, paso a paso

Esta es la guía que me habría gustado tener antes de mi propio lanzamiento: qué ocurre de verdad, y en qué orden, cuando apuntas Claude Code al repositorio de LaunchRepo y le pides que lance tu producto en directorios. Sigue los documentos del repositorio —START.md, ONBOARDING.md y BROWSER-SETUP.md— en lenguaje llano, señalando dónde tú tienes que actuar. Nada es tan específico de Claude Code que no funcione con Codex o Cursor; las páginas de agentes cubren las diferencias. Claude Code es simplemente el que uso yo.

Dos expectativas antes de empezar. Primera: esto no es un lanzamiento de un clic. El agente hace el trabajo repetitivo, pero tú conectas el navegador, apruebas los textos, resuelves los CAPTCHA y confirmas qué está publicado. Segunda: ningún paso de abajo promete una ficha; cada directorio decide por sí mismo qué publica, y muchos planes gratuitos tardan semanas.

Paso 0: qué necesitas

• El repositorio. Tras la compra recibes una invitación a un repositorio privado de GitHub. Clónalo.
• Python 3.10 o superior en macOS o Linux. El tracker, el panel y los scripts auxiliares son Python puro, sin dependencias que instalar.
• Claude Code con una integración de navegador. Un terminal solo no puede rellenar formularios; la configuración del navegador del repositorio usa Chrome DevTools MCP, que necesita Node.js para npx.
• Chrome 144 o superior, con tu cuenta de Google y tu buzón iniciados: los que quieres que conozcan los directorios.
• Los datos de tu producto: nombre, URL, una descripción real, precios, fase de lanzamiento, capturas auténticas y un logo. No deseos de marketing; lo que existe hoy.

Paso 1: el prompt de inicio

Abre la carpeta clonada en Claude Code y pega el prompt de START.md, exactamente como está escrito:

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.

El prompt está en inglés y se queda en inglés; el agente te hablará en tu idioma en cuanto haya leído las instrucciones. Lo que ocurre después es determinista: el agente lee AGENTS.md, crea un espacio de trabajo privado junto a la copia del repositorio —tus productos y credenciales nunca viven en el repositorio de entrega—, arranca el panel local y responde con un enlace 127.0.0.1. Ábrelo. Todo lo demás puede hacerse en esa pestaña o en el chat; los formularios del panel escriben los mismos archivos que lee el agente.

Si prefieres hacerlo tú mismo, el repositorio documenta dos comandos: uno inicializa el espacio de trabajo, el otro arranca el panel. Un flag --demo sirve un espacio desechable con un producto ficticio para echar un vistazo primero.

Paso 2: la entrevista de onboarding

ONBOARDING.md indica al agente que dirija tu primera sesión fase por fase y que lea los archivos existentes antes de preguntar algo dos veces. En la práctica se parece a una entrevista.

Dónde estamos. El agente explica qué es el espacio de trabajo y pregunta el nombre, la URL y la carpeta local con el código o las notas de tu primer producto. Inspecciona esas fuentes antes de preguntar más y determina tu sistema operativo, tu agente y qué herramientas de navegador puede invocar de verdad; tiene prohibido afirmar que dispone de herramientas que la sesión no tiene.

Un hogar privado. El agente te ayuda a crear tu propio remoto privado para el espacio de trabajo y explica, sin rodeos, que las credenciales reutilizables guardadas allí las puede leer cualquiera con acceso a ese repositorio, incluido su historial. Tú decides si las credenciales van al espacio de trabajo, a un gestor de secretos (solo referencias) o a ninguna parte. El archivo del espacio de trabajo registra esa decisión.

El producto. Un script crea una carpeta de producto a partir de un slug corto; después el agente rellena product.json con tus respuestas: público, problema, diferenciador, funciones reales, precios o prueba gratuita, fase de lanzamiento, capturas y logo. Un taller de textos lo convierte en copy.md con variantes para distintos límites de campo. Lo desconocido se queda vacío: el agente tiene instrucciones de no derivar capacidades de la competencia ni convertir funciones planeadas en disponibles.

Esta fase también fija la fecha más temprana de lanzamiento. Muchos directorios gratuitos ponen los envíos en una cola de revisión; la confirmación puede tardar semanas. El agente pregunta si hay una fecha antes de la cual no debe publicarse nada, la escribe en product.json, y el tracker se niega a marcar nada como programado antes de esa fecha.

Identidad. identity.json guarda el nombre público, el correo que quieres que usen los directorios, tu alias y los datos de organización que estás dispuesto a publicar. Sigue una breve sesión de briefing de relaciones públicas en la que corriges cómo te describe el agente antes de que nada de eso llegue a una ficha pública.

Paso 3: conectar Chrome y tu buzón

Este es el paso que la gente se salta y luego se pregunta por qué el agente no puede iniciar sesión. El agente necesita un navegador que tú puedas ver y supervisar. BROWSER-SETUP.md ofrece dos rutas.

Ruta A: tu Chrome de siempre. Comprueba chrome://version (144+), abre chrome://inspect/#remote-debugging en el Chrome que quieres que use el agente y activa allí la depuración remota. Después añade Chrome DevTools MCP a la configuración MCP de Claude Code con --autoConnect. Lanza una acción inofensiva desde el agente y aprueba tú mismo el aviso de conexión de Chrome, en la ventana correcta. Un proceso MCP en marcha no demuestra acceso al navegador; una pestaña visible que se mueve, sí.

Ruta B: un perfil dedicado. Arranca Chrome con su propio directorio de datos de usuario dentro del espacio de trabajo y un puerto local de depuración remota, inicia sesión en las cuentas necesarias en esa ventana y apunta la configuración MCP a --browserUrl en lugar de --autoConnect. Nunca los dos a la vez, nunca con el puerto expuesto fuera de localhost.

En macOS, concede solo los permisos de Automatización, Accesibilidad o Grabación de pantalla que tu integración necesite; una conexión DevTools pura normalmente no necesita ninguno. El aviso de conexión de Chrome puede repetirse tras reconectar: es un control de seguridad, no un fallo, y el repositorio indica al agente que no prometa eliminarlo.

Luego la prueba de humo: el agente abre una pestaña nueva, navega a la portada pública de un directorio, lee su título principal y te dice qué pestaña usó. Tú miras la misma ventana. Después inicia sesión en un directorio objetivo y revisa el menú de cuenta para confirmar la identidad; completar OAuth no demuestra estar conectado en el sitio de destino. Por último confirma el acceso al buzón, porque los correos de verificación completan los registros. Reenviar códigos a mano es un recurso admitido; el tracker lo registra como relevo humano, no como acceso automatizado.

Paso 4: permisos, una vez por producto

Antes de enviar nada, el agente lee WEBSITE-AND-EMAIL.md y hace un puñado de preguntas que no volverá a hacer: dónde vive el código de tu web, cómo se despliega, qué rama es producción, si puede añadir al pie los badges que exigen algunos directorios y subirlos, y si están autorizados los registros gratuitos, los envíos finales gratuitos y las acciones concretas con correos de verificación. Las respuestas, la fecha y el alcance exacto van a authorizations.json. El gasto se queda en cero: el agente tiene orden de rechazar todo upsell de pago.

Negarte a los badges está bien; solo descarta los directorios que los exigen. Lo que no debes hacer es extender los permisos de un producto a otro. El archivo es por producto a propósito.

Paso 5: el primer resultado útil

Ahora el agente ejecuta doctor.py, que separa la configuración que falta de los permisos que rechazaste, y elige del índice de playbooks y del catálogo tres a cinco directorios que encajen con tu producto; explica el encaje y los requisitos y empieza por una vía gratuita accesible. Para cada directorio el playbook guía el mismo bucle: buscar primero una ficha existente, comprobar que es el sitio correcto, preparar el texto dentro de los límites de campo, confirmar que nada cuesta dinero, enviar solo dentro de tu autorización y registrar el resultado real.

Cuenta con relevos. Un CAPTCHA, una verificación en dos pasos, una cuenta poco clara o un badge obligatorio detienen la ejecución: el agente registra prepared_needs_human, el panel muestra la plataforma bajo «te necesita» y tú terminas ese paso en tu navegador. Es a propósito: el repositorio prohíbe evasiones y cambios furtivos.

Un buen primer resultado suele ser una revisión enviada, no una página publicada. Es normal.

Paso 6: qué significan los estados del tracker

Cada resultado pasa por record.py a submissions.csv, y el panel muestra los mismos once estados. Cada uno va ligado a una observación mínima, para que un «hecho» no pueda inflarse. Con mis palabras:

• draft — el trabajo está preparado, pero el envío final no se confirmó.
• prepared_needs_human — algo concreto lo bloquea y solo tú puedes actuar: CAPTCHA, 2FA, una cuenta poco clara.
• submitted_pending_review — la plataforma recibió explícitamente el envío y la moderación sigue pendiente.
• queued — la plataforma confirmó una posición en cola o un estado de lista de espera.
• scheduled — la plataforma confirmó una fecha de lanzamiento igual o posterior a tu fecha más temprana; cualquier aprobación pendiente queda en la nota.
• live — se verificó una ficha pública sin etiqueta de pendiente. Requiere la URL pública y tu confirmación.
• already_listed — se encontró y verificó una ficha pública existente; mismo requisito de URL y confirmación que live.
• blocked — la elegibilidad, la capacidad de la cuenta o un dato obligatorio ausente impiden avanzar.
• deferred_paid — la única vía utilizable exige pago; no se compró nada.
• not_a_fit — el producto no cumple los criterios de público o de ficha.
• unavailable — la vía o la plataforma no se pueden usar ahora mismo; el problema observado queda anotado.

De ahí salen tres consecuencias. Una pantalla de agradecimiento no es live. Una casilla de distribución a socios en un sitio no cuenta como segundo envío hasta que la segunda plataforma lo confirma. Y scheduled en un plan gratuito puede tardar semanas en publicarse. La guía de seguimiento de estados explica cómo mantener todo eso separado.

Paso 7: dejar un espacio de trabajo reanudable

Al final de una sesión el agente actualiza la lista de onboarding solo con lo que observó, escribe evidencia no sensible y pasos abiertos en SESSION.md, apunta las próximas fechas en FOLLOW-UP.md y ejecuta una comprobación de privacidad de git antes de subir a tu remoto privado. La siguiente sesión —tuya o de otro agente— lee primero el tracker, prioriza relevos y lanzamientos programados por verificar, y después los envíos pendientes cuya ventana de revisión ya pasó. Recomprueba los registros existentes en lugar de enviar otra vez para adelantar en la cola.

Esa capacidad de reanudar es todo el sentido. Tu segundo producto reutiliza la configuración del navegador, la identidad, el patrón de autorizaciones y los playbooks; solo product.json y los textos son nuevos.

Por dónde seguir

La página de Claude Code tiene el mismo prompt de inicio, la lista de relevos y las notas del navegador en una sola pantalla. Cómo funciona muestra los seis pasos con el vídeo del fundador. En el catálogo de directorios puedes leer algunos playbooks públicos antes de decidir, y en la página de precios se compra el repositorio, una sola vez.

Fuentes: START.md, ONBOARDING.md, BROWSER-SETUP.md y RUNBOOK.md del repositorio de LaunchRepo (notas de versión en el changelog); el prompt de inicio se cita literalmente de prompts/start.md. No se dan cifras de tiempo ni de resultados porque no se ha medido ninguna entre clientes.