Checklist de Product Hunt para desarrolladores en solitario

Product Hunt es el único directorio del que casi todos los desarrolladores en solitario han oído hablar, y aquel en el que un envío apresurado sale más caro: el día del lanzamiento es un momento fijo y todo tu entorno va a mirar esa página. Esta checklist está escrita para quien construye, promociona y lanza solo, sin un equipo que revise los textos a medianoche. Se basa en nuestro propio envío de seomap.dev, documentado en el playbook público de Product Hunt, y en el briefing de representación que viene en el repositorio de LaunchRepo. Cuando aparece una cifra, es lo que mostraba el formulario en la fecha observada: Product Hunt cambia sus formularios, así que vuelve a comprobarlo antes de pegar nada definitivo.

Una expectativa por delante: la checklist te lleva hasta un lanzamiento scheduled con textos honestos e imágenes reales. No promete votos, ni un puesto en la portada, ni tráfico. Nadie puede, y las tácticas que dicen lograrlo son justo las que prohíben las reglas de la plataforma.

Antes de tocar el formulario

• Busca primero. Busca el nombre de tu producto y tu dominio en el sitio público y en «My Products» con la sesión iniciada. Un borrador antiguo o una ficha que creó otra persona es un duplicado esperando a ocurrir. El artículo sobre los estados del tracker explica por qué registramos already_listed aparte.
• Decide quién es el maker. Los lanzamientos de Product Hunt los lidera una persona. Crea un perfil personal con un nombre real o el alias que usas de verdad, una foto y una biografía de una línea. Si la cuenta de tu empresa y la tuya personal son cosas distintas, decide ahora cuál va asociada.
• Ejecuta el briefing de representación. El PR-BRIEFING.md del repositorio hace tres preguntas antes de que ningún dato personal llegue a una ficha pública: individuo, empresa o ambos; qué nombre, alias y vinculación pueden aparecer; y qué no debe decirse nunca de ti. Después redacta una biografía de maker de una línea, una frase de presentación del lanzamiento y una frase de «por qué construí esto», y te las muestra literalmente para que las corrijas. Aprobar, corregir, guardar. Siendo desarrollador en solitario eres el único revisor, y justo por eso ayuda mirar esas tres frases por separado en lugar de dentro de un formulario.
• Anota los hechos del producto, no los deseos. Público, problema, qué existe hoy, el precio tal cual es, fase de lanzamiento. Una prueba con créditos limitados no es un plan gratuito. Las funciones planeadas se quedan fuera de la descripción.

Los textos: los límites que observamos

En la fecha observada, el formulario de envío permitía un eslogan de 60 caracteres y una descripción de 500 caracteres. Ambos son más cortos que el primer borrador de casi cualquiera, y en ambos tiene que caber la versión honesta de tu producto.

• Eslogan de 60 caracteres como máximo. Un beneficio, en palabras llanas. Cuéntalos: «con IA» y repetir el nombre del producto se comen un tercio del presupuesto para nada.
• Descripción de 500 caracteres como máximo. Para quién es, qué hace, cuánto cuesta. Sin número de clientes, ingresos, premios ni integraciones que no puedas señalar.
• Prepara variantes. El taller de textos de LaunchRepo produce copy.md con versiones para distintos límites de campo, así el eslogan de 60 caracteres de Product Hunt y el límite distinto del siguiente directorio salen de los mismos hechos aprobados en lugar de reescribirse a última hora.
• Vuelve a comprobar los límites ese mismo día. Eran 60 y 500 cuando lo miramos; trátalo como un dato, no como una regla.

Recursos: reales, actuales, tuyos

• Logo en el tamaño pedido, sobre un fondo que sobreviva a una tarjeta oscura.
• Imágenes de galería del producto real. Capturas de lo que ve un usuario esta semana, no un mockup del rediseño. Si el producto tiene vídeo, añádelo; si no lo tiene, no falsifiques una miniatura.
• URL del producto que resuelva y que coincida con el nombre y el dominio de tu perfil de maker.
• Categoría que elegiría por ti alguien de fuera. El formulario usa selectores nativos; verifica el valor realmente seleccionado después de hacer scroll, porque en la ejecución observada la selección podía diferir en silencio de la que aparecía resaltada.

El precio y las comprobaciones de honestidad

Product Hunt pregunta cómo está tarificado el producto. Un producto de pago con prueba gratuita debe representarse como de pago con prueba, no como «gratis». Suena obvio hasta que una página de lanzamiento dice «gratis» y el primer comentario pregunta por qué el registro pide tarjeta.

Dos cosas que el playbook deja explícitas, y que el AGENTS.md del repositorio repite para cada directorio:

• Nada de pedir votos. No pidas votos a amigos, comunidades ni clientes; no compres interacción; no montes una campaña de «apóyanos en Product Hunt» que se lea como una petición de voto. Cuenta que has lanzado y deja que decidan. Es una regla de la plataforma, y el tracker trata los votos o comentarios fabricados igual que los testimonios inventados: prohibidos.
• Nada de testimonios inventados. Una cita va a la página solo si la dijo una persona real y aceptó que se publicara.

La fecha de lanzamiento: deliberada, no inmediata

Lo más útil que puede hacer un desarrollador en solitario en Product Hunt es elegir la fecha en lugar de pulsar «lanzar ahora» porque el formulario por fin está relleno.

• Fija tu fecha más temprana de lanzamiento. En LaunchRepo vive en product.json como earliest_launch_date; el tracker se niega a registrar una plataforma como scheduled antes de esa fecha. Si tu web, tu página de precios o tu onboarding no están listos, esa fecha es posterior a hoy.
• Elige un día en el que puedas estar conectado. Un lanzamiento en solitario significa que respondes tú los comentarios. Escoge un día sin entrega para un cliente, no un día de viaje.
• Confirma la zona horaria. El flujo observado mostraba una fecha y una zona horaria en la confirmación. Registra las dos. Un lanzamiento programado a las «00:01» cae en un día distinto en hora del Pacífico que en Berlín.
• No cuentes un borrador guardado como programado. El playbook hace esa distinción a propósito: un borrador es trabajo guardado; scheduled es la cuenta confirmando una fecha. Solo lo segundo entra en tu tracker como scheduled, y aun así no dice nada sobre si la página será destacada ni sobre dónde aparecerá.

Qué significa «scheduled» y qué no

En nuestra propia ejecución, el flujo de Product Hunt llegó a un lanzamiento programado. Eso confirma una fecha. No confirma la publicación, ni una posición en la portada, ni visibilidad alguna. El día del lanzamiento, el paso de resultado del playbook es abrir la página pública del producto e inspeccionarla antes de registrar live, porque live en el tracker de LaunchRepo exige una URL pública verificada y tu confirmación explícita, no una entrada de calendario.

Esto importa más en Product Hunt que en la mayoría de directorios, porque la distancia entre «lo he programado» y «la gente puede verlo» es exactamente la distancia sobre la que los desarrolladores en solitario tienden a anunciar. Anuncia el día, desde la página pública.

El día del lanzamiento, para una sola persona

• Abre la página pública lo primero. Comprueba que el eslogan, las imágenes y la atribución del maker se muestran como pretendías.
• Publica la presentación aprobada —la frase del briefing de representación— donde hables normalmente de tu trabajo. Sin pedir votos.
• Responde tú mismo cada comentario, con tus palabras. Es el único sitio donde ser un maker solo es una ventaja.
• Registra el resultado con honestidad. live con la URL pública si la página es pública; scheduled con una nota si todavía no lo es; lo que haya pasado de verdad si algo salió mal. La guía de seguimiento de estados cubre los casos límite.

Después del día

Product Hunt es un directorio dentro de un catálogo de 346. Los playbooks del repositorio lo tratan como a los demás: buscar primero, verificar la identidad, preparar los textos dentro de los límites, confirmar que nada cuesta dinero, enviar solo dentro de tu autorización y registrar lo observado. Un desarrollador en solitario que ha hecho eso una vez para Product Hunt ya tiene hecha la parte difícil para la siguiente plataforma: los hechos, las variantes de texto y los recursos se reutilizan, y la guía paso a paso con Claude Code muestra cómo un agente recorre el resto de la lista a partir de los mismos archivos.

Si estás eligiendo qué directorios vienen después, mejores directorios de startups 2026 agrupa el catálogo por categorías, y la página para indie hackers describe la configuración de un lanzamiento de una sola persona. El repositorio en sí —playbooks, plantilla de producto, tracker, panel local— se compra una vez en la página de precios.

Fuentes: el playbook público de Product Hunt (límites del formulario y flujo tal como se observaron el 2026-09-13), PR-BRIEFING.md, ONBOARDING.md, AGENTS.md y RUNBOOK.md del repositorio de LaunchRepo. No se dan cifras de votos, posiciones ni tráfico porque no se midió ninguna, y tampoco se promete ninguna.