Lanzamiento en directorios con presupuesto cero

La mayoría de artículos sobre lanzamientos en directorios dan por hecho un presupuesto: un puesto destacado aquí, un «sáltate la cola» allá, un plan de pago en los sitios de reseñas. Este da por hecho lo contrario. La regla de nuestra propia ejecución con seomap.dev fue gasto cero —no «barato», cero— y los playbooks de LaunchRepo heredan esa regla: al agente se le prohíbe gastar dinero, empezar pruebas con tarjeta y aceptar mejoras de pago. Lo que sigue es cómo es un lanzamiento con esa restricción: más lento, con más espera y más relevos, y con un tracker que se mantiene honesto al respecto.

La regla de gasto cero, dicha con precisión

En AGENTS.md, las instrucciones del repositorio para el agente, la regla es corta: nunca gastes dinero ni aceptes ofertas ajenas; no empieces pruebas que requieran tarjeta; no aceptes mejoras de pago. Está junto a las otras reglas duras —nada de recuentos de clientes inventados, nada de votos fabricados, nada de evadir límites de cuenta— porque es del mismo tipo: un límite que el agente no puede cruzar ni cuando el formulario convierte cruzarlo en el camino de menor resistencia.

Dos consecuencias. Cualquier directorio cuya única vía utilizable cuesta dinero se registra como deferred_paid: nada comprado, la vía anotada, la decisión en tus manos. Y cualquier upsell que aparezca dentro de un flujo gratuito hay que rechazarlo explícitamente, que es más trabajo de lo que parece.

Rechazar upsells es un paso, no un detalle

Las vías gratuitas rara vez son un solo botón. En nuestra ejecución, el camino gratuito de varias plataformas pasó por una oferta, un rechazo, una confirmación y una segunda oferta antes de la página de éxito. Los playbooks públicos documentan lo que vimos:

• TinyLaunch: el lanzamiento Standard ofrecía servicios opcionales, que había que dejar en ninguno; después de programar apareció un segundo diálogo de mejora, y el camino gratuito solo continuaba por una opción «continue with free launch». El playbook de TinyLaunch enumera la secuencia.
• SaaSHub: había que inspeccionar el plan de envío antes de enviar; la opción gratuita observada está documentada como una observación, no como una promesa permanente. El playbook de SaaSHub lo cubre.
• PitchWall: el plan disponible se muestra antes de la importación de la URL; el playbook de PitchWall indica revisarlo, junto con el consentimiento de inicio de sesión y los requisitos de newsletter, antes de continuar.

La guía de planificación de gasto cero lo convierte en regla: revisa cada pantalla final. Comprueba el total real, comprueba la confirmación final y vuelve a abrir los campos guardados para verificar que persistieron. Un adelanto de cola que no querías comprar sigue siendo una compra.

Nada de adelantar cola, nada de atajos

El presupuesto cero tienta hacia cosas que son gratis pero incorrectas. Los playbooks las prohíben todas, una por una:

• Comprar un adelanto de cola: fuera, obviamente. Pero también: volver a enviar para subir en una cola. El runbook le dice al agente que recompruebe el registro existente en lugar de enviar otra vez.
• Crear una segunda cuenta para sortear un límite. El flujo gratuito observado en Uneed permitía un lanzamiento pendiente por cuenta y bloqueaba un envío nuevo mientras un producto esperaba. El playbook de Uneed lo registra como blocked con una acción siguiente, no como un problema que rodear.
• Borrar otro producto para liberar un hueco. Misma respuesta.
• Afirmar una elegibilidad que no has verificado. La vía básica observada en Fazier exigía comentarios en la comunidad, un badge visible y un domain rating por encima de cero en un comprobador concreto. Un producto que no lo cumple se detiene antes de atestiguar el cumplimiento: blocked, no «casi». El playbook de Fazier es explícito.

Nada de esto es moralina. Los directorios que pillan atajos retiran fichas, y una ficha retirada después de semanas de espera es el resultado más caro que puede tener una ejecución gratuita.

Los relevos humanos son donde se va el tiempo

Una ejecución solo gratuita tiene más relevos que una de pago, porque las vías de pago son a menudo justo las que se saltan una revisión, un badge o una verificación. El agente se detiene y registra prepared_needs_human con la siguiente acción exacta para:

• CAPTCHA y verificación en dos pasos. Nunca se saltan, nunca los resuelve el agente. Los completas tú en el navegador que conectaste.
• Badges en la web. Varios planes gratuitos exigen el badge del directorio en tu sitio. Eso es un cambio en la web de tu producto, así que necesita tu autorización registrada —una vez por producto— y los recursos oficiales del badge. Negarte está bien; simplemente descarta esos directorios.
• Correos de verificación. Los registros terminan por correo. Si el agente tiene acceso al buzón en el navegador conectado, lee el código él mismo; si no, se lo reenvías tú, y el tracker registra un relevo humano en lugar de acceso automatizado.
• Decisiones sobre vías de pago. Las filas deferred_paid te esperan. A veces la respuesta es «no, sáltatelo»; a veces un directorio importa lo suficiente como para pagar una vez, fuera de la ejecución, y registrarlo tú mismo.

El panel local agrupa todo esto bajo «te necesita». En una ejecución con presupuesto cero, esa lista es la lista de tareas de verdad; la parte del agente está casi terminada cuando aparece.

Tiempos de revisión: semanas, no días

El ajuste más grande es el tiempo. Los planes gratuitos hacen cola. La sesión de onboarding del repositorio obliga al agente a decirlo sin rodeos antes del primer envío: muchos directorios gratuitos ponen los envíos en una cola de revisión, y la confirmación o la publicación pueden tardar varias semanas después de enviar, no días.

Observaciones concretas de los playbooks: el envío completado en PitchWall se quedó como Under Review con una estimación superior a 30 días. TinyLaunch confirmó un hueco semanal con la aprobación aún pendiente. SaaSHub publicó una página que se quedó etiquetada como Pending approval. Ninguna de estas cosas es una queja —así es la revisión gratuita—, pero un tracker con una sola columna de «hecho» habría contado las tres como terminadas el primer día.

Por eso product.json lleva un earliest_launch_date y por eso el runbook le dice al agente que no se invente un SLA de plataforma: si un directorio no da tiempos de revisión, acuerdas una fecha razonable de seguimiento y compruebas entonces. El artículo sobre los estados de envío repasa los estados exactos y por qué scheduled y submitted_pending_review se mantienen separados.

Qué muestra nuestro propio piloto

La prueba pública de todo esto es nuestro propio producto, seomap.dev, y está limitada a propósito a lo que puedes verificar. La ejecución actual ha enviado seomap.dev a 160+ directorios; cada uno está publicado o esperando a que la plataforma lo publique. Las fichas verificables públicamente están enlazadas desde la página sobre nosotros. No publicamos URL de cuentas, correos ni capturas de correo, y no publicamos un recuento de «publicadas» que incluya páginas pendientes.

Seis de esas plataformas están documentadas en playbooks públicos y, por sí solas, muestran todo el abanico: Product Hunt llegó a scheduled, SaaSHub se quedó en submitted_pending_review tras una etiqueta Pending approval, TinyLaunch terminó en scheduled con la aprobación pendiente, PitchWall pasó a submitted_pending_review con una estimación de más de 30 días, Uneed devolvió blocked por un límite de cuenta y Fazier blocked por una regla de elegibilidad. Esa distribución, y no una única cifra, es la imagen honesta de una ejecución con presupuesto cero.

Presupuestar intentos cuando el presupuesto es cero

El «presupuesto cero» sigue teniendo un coste: el kit, una vez, y el uso de tu agente, facturado por tu proveedor. La guía de gasto cero propone dividir el coste del kit entre los productos por los intentos previstos. El ejemplo que usa —100 € entre cuatro productos con seis intentos cada uno son unos 4,17 € por intento, sin contar el coste del agente— es aritmética, no una previsión. Si solo encajan tres directorios con tu producto, la asignación se duplica. Nada de eso predice aceptación, tráfico ni posiciones.

Lo que te compra el presupuesto cero es una respuesta limpia a la pregunta que todo directorio acaba haciendo: «¿pagaste por esto?». No. Cada ficha del tracker llegó ahí por la vía gratuita, dentro de las reglas de la plataforma, con una persona entrando allí donde la plataforma quería una.

Ejecutar la tuya

Si quieres aplicar la misma restricción: la página para indie hackers describe la configuración de una sola persona, la guía de planificación de gasto cero es la checklist que sigue el agente, y la guía paso a paso con Claude Code muestra una sesión completa, relevos incluidos. El repositorio —346 playbooks, plantilla de producto, tracker, panel— se compra una sola vez en la página de precios, y los playbooks nunca autorizarán una compra en tu nombre.

Fuentes: AGENTS.md, ONBOARDING.md y RUNBOOK.md del repositorio de LaunchRepo; los playbooks públicos de TinyLaunch, SaaSHub, PitchWall, Uneed y Fazier (observados el 2026-09-13); la guía de planificación de gasto cero. La cifra de 160+ es el recuento de envíos del propio piloto a fecha de este artículo; cuenta envíos, no fichas publicadas.