Enviado, pendiente, programado, live: estados que importan

Todas las hojas de cálculo para envíos a directorios empiezan igual: una columna llamada «estado», tres valores —pendiente, hecho y quizá «esperando»— y un total abajo que sube cada vez que alguien pulsa enviar. Dos semanas después el total dice 40, el número de fichas que un desconocido puede encontrar de verdad dice 6, y nadie sabe explicar la diferencia sin volver a abrir todas las cuentas.

La diferencia no es dejadez. Es que a «hecho» se le pidió responder cinco preguntas distintas a la vez. Este artículo trata de esas preguntas, de por qué el tracker de LaunchRepo le da a cada una su propio estado, y de dos ejemplos de nuestra propia ejecución con seomap.dev en los que un único «hecho» habría sido incorrecto.

Una columna, cinco preguntas

Cuando envías un producto a un directorio, a quien le importa el resultado quiere saber cosas distintas:

• ¿Está hecho el trabajo por mi parte? ¿Rellené todo y pulsé el botón?
• ¿Lo recibió la plataforma? Una página de agradecimiento, un correo, una entrada en la cuenta.
• ¿Está esperando algo? Moderación, un hueco en la cola, una aprobación, una fecha.
• ¿Puede verlo el público? Una URL que carga para alguien sin sesión iniciada y que no lleva una etiqueta de «pendiente».
• ¿Tengo que hacer yo algo? Un CAPTCHA, una verificación en dos pasos, un badge en mi web, una decisión sobre una vía de pago.

«Hecho» responde la primera pregunta y da por respondida la cuarta en silencio. Así es como un total de 40 se convierte en un total de 6.

Los estados, y la pregunta que responde cada uno

El tracker de LaunchRepo (record.py escribiendo submissions.csv, y las mismas reglas en el panel local) usa once estados. Cada uno está ligado a una observación mínima: lo que tienes que haber visto de verdad antes de registrarlo. Agrupados por la pregunta que responden:

Trabajo por tu parte

• draft — la preparación existe, el envío final no se confirmó. Un formulario guardado es un borrador.
• prepared_needs_human — algo concreto bloquea el trabajo preparado y solo una persona puede desbloquearlo: CAPTCHA, 2FA, un estado de cuenta poco claro. La nota dice exactamente qué.

La plataforma lo recibió

• submitted_pending_review — la plataforma confirmó explícitamente la recepción y la moderación sigue abierta.
• queued — la plataforma confirmó una posición en cola o un estado de lista de espera. Distinto de estar en revisión: hay una fila, y estás en ella.
• scheduled — la plataforma confirmó una fecha de lanzamiento igual o posterior a tu fecha más temprana. Si la aprobación sigue pendiente, eso va en la nota; el estado se queda en scheduled.

El público puede verlo

• live — se verificó una ficha pública, sin etiqueta de pendiente. Al registrarlo exige la URL pública y una marca de confirmación explícita.
• already_listed — se encontró y verificó una ficha pública ya existente antes de que enviaras nada. Mismo requisito de URL y confirmación.

Se detuvo, por un motivo que puedes nombrar

• blocked — elegibilidad, capacidad de la cuenta o un dato obligatorio que no tienes.
• deferred_paid — la única vía utilizable cuesta dinero; no se compró nada.
• not_a_fit — el producto no cumple el público ni los criterios del directorio.
• unavailable — la vía o la plataforma no se pudieron usar; la nota registra lo observado.

Once parecen muchos. En la práctica cada uno existe porque fundirlo con su vecino produjo un informe incorrecto al menos una vez.

Ejemplo 1: SaaSHub, pública pero pendiente

El envío a SaaSHub, documentado en el playbook público de SaaSHub, produjo una página de producto accesible públicamente. Cualquiera con el enlace podía abrirla. También llevaba una etiqueta visible: Pending approval («pendiente de aprobación»).

Un tracker de una sola columna lo registra como hecho, o incluso como publicado: al fin y al cabo, la página carga. La regla de LaunchRepo es la contraria: la accesibilidad pública por sí sola no es prueba de aceptación. La ficha se queda en submitted_pending_review mientras la página diga pendiente, y pasa a live solo después de que alguien la abra otra vez, no vea etiqueta de pendiente y registre la URL con la marca de confirmación. En el caso de SaaSHub eso significó que el recuento de publicadas no subió el día del envío, y que el archivo de seguimiento se llevó una fecha para volver a mirar.

El detalle extra que añade el playbook: en SaaSHub la verificación de propiedad del dominio es una petición aparte del inicio de sesión. Es una segunda cosa que puede quedar pendiente por su cuenta, y una nota en la fila es el sitio adecuado para ella.

Ejemplo 2: TinyLaunch, programado con la aprobación pendiente

TinyLaunch, documentado en el playbook de TinyLaunch, ofrecía un hueco de lanzamiento semanal en el futuro. La vía observada pasó por un lanzamiento Standard, un paso de servicios opcionales puesto a ninguno, una confirmación de programación y un segundo diálogo de mejora con una opción «continue with free launch» antes de que apareciera la página de éxito. El panel mostró después la fecha confirmada y, al lado, Waiting for approval («esperando aprobación»).

Dos formas equivocadas de registrar esto: live, porque hay una fecha en un calendario; o submitted_pending_review, porque falta la aprobación. El tracker registra scheduled con la fecha confirmada pasada de forma explícita, y mantiene la aprobación pendiente en la nota. Sobreviven los dos hechos: existe una fecha, y puede no mantenerse. El artículo sobre el lanzamiento con presupuesto cero cubre la parte de upsell de ese mismo flujo.

Aquí también importa la fecha más temprana de lanzamiento. product.json lleva un earliest_launch_date; el tracker se niega a registrar scheduled con una fecha anterior a esa. Un desarrollador en solitario que puso el suelo en «después de que salga la página de precios» no puede programar sin querer un lanzamiento para mañana solo porque un directorio le ofreció el hueco.

Tres reglas que salen de los estados

Una pantalla de agradecimiento no es una ficha publicada. Es, como mucho, submitted_pending_review. La mayoría de directorios que revisan a mano tardan de días a semanas; varios planes gratuitos de nuestra ejecución tardaron más. La guía de seguimiento de estados es explícita: una estimación larga de revisión no es ni un plazo ni una garantía.

Un envío es una fila. Algunos directorios ofrecen una casilla de «distribuir también a nuestros sitios socios». Marcarla no crea un segundo envío hasta que la segunda plataforma confirma la recepción por su cuenta. El tracker mantiene una fila actual por plataforma y exige una sustitución explícita para cambiarla, así que una casilla de socios no puede inflar el recuento en silencio.

Los relevos humanos son un estado, no un fallo. Cuando un agente se topa con un CAPTCHA o una verificación en dos pasos, registra prepared_needs_human con la siguiente acción exacta y se detiene. El panel los agrupa bajo «te necesita». Marcarlos de cualquier otra forma —reintentando, como «pendiente», saltándoselos— o evade un control de la plataforma o esconde trabajo que sigues teniendo que hacer.

Por qué un agente lo necesita más que tú

Si envías a cinco directorios a mano, recuerdas cuál está pendiente y cuál te mostró un calendario. Un agente de IA que ejecuta una sesión, la cierra y se reinicia mañana —quizá otro agente, en otra máquina— no lo recuerda. Lee primero el tracker y decide qué hacer a partir del estado:

• prepared_needs_human y los lanzamientos scheduled que toca verificar van primero.
• Las filas submitted_pending_review cuya ventana de revisión ya pasó se recomprueban: el registro existente, no un envío nuevo para adelantar en la cola.
• Las filas live se dejan en paz.

Cada una de esas decisiones es incorrecta si el estado es incorrecto. Registrar live la página de SaaSHub habría significado que nadie comprobara nunca si llegó a aprobarse. Registrar TinyLaunch como enviado habría significado que nadie verificara el lanzamiento en la fecha confirmada. Los estados son la memoria del agente, y la guía paso a paso con Claude Code muestra cómo una ejecución los lee al principio de cada sesión.

Cómo es un buen informe

En lugar de «40 hechos», el panel muestra algo así: 6 publicadas con URL pública, 21 en revisión con fecha para volver a mirar, 4 programadas con fecha confirmada, 3 que te necesitan, 2 aplazadas porque no existía vía gratuita, 4 sin encaje. El total sigue siendo 40. Cada número se puede defender, y cada grupo tiene una acción siguiente obvia.

Para eso sirve un tracker. No para impresionar, sino para decirle a la siguiente persona, o al siguiente agente, qué es verdad y qué hacer.

Si estás montando tu propia ejecución, cómo funciona LaunchRepo muestra dónde encaja el tracker en el flujo, la página para fundadores de SaaS cubre la configuración de un producto con un calendario de lanzamiento real, y la página de precios tiene la licencia de pago único del repositorio en el que viene el tracker.

Fuentes: RUNBOOK.md y AGENTS.md del repositorio de LaunchRepo (tabla de estados y observaciones mínimas), los playbooks públicos de SaaSHub y TinyLaunch (observados el 2026-09-13) y la guía de seguimiento del estado de los envíos. Las cifras del informe de la última sección son ilustrativas, no medidas.