LaunchRepoA primeira pergunta que o onboarding do kit faz sobre calendário não é «quando queres lançar?» mas «há uma data antes da qual nada deve ficar público?». São perguntas diferentes, e a diferença é o tema deste artigo. A versão curta: as submissões a diretórios não ficam online quando as submetes, ficam online quando o diretório lá chega, e se queres uma semana de lançamento em vez de um lançamento espalhado precisas de uma data mínima, não de uma data-alvo.
A funcionalidade, num parágrafo
Desde a versão de 15 de setembro de 2026, o product.json tem um campo chamado earliest_launch_date. Vazio significa sem data mínima. Se tiver uma data, o record.py do tracker recusa marcar qualquer plataforma como scheduled com uma data de lançamento anterior, e recusa scheduled sem --launch-date de todo. O onboarding pede o valor logo ao início, e o painel local mostra a data mínima ao lado do estado agendado. É toda a funcionalidade: um campo, uma recusa, uma pergunta feita antes de qualquer submissão. O changelog tem a nota de lançamento.
É pequena de propósito. Não atrasa submissões, porque não pode; o agente não decide quando um diretório publica. O que faz é impedir que a única coisa sob o teu controlo corra mal: um agente a confirmar uma data de lançamento numa plataforma com calendário, para uma semana que não querias.
Porque é que os diretórios gratuitos publicam mais tarde do que pensas
Se nunca submeteste um produto a um diretório pela via gratuita, os prazos surpreendem. Dos guias públicos deste site, todos observados em setembro de 2026:
- A SaaSHub produziu uma página acessível publicamente logo após a submissão, com a etiqueta Pending approval. Acessível não é aceite; o tracker mantém
submitted_pending_reviewaté a etiqueta desaparecer. - A PitchWall aceitou a submissão para Under Review com uma estimativa de revisão superior a 30 dias.
- A TinyLaunch ofereceu um lugar semanal futuro na via standard e deixou a aprovação em aberto depois de a data ser escolhida: scheduled, com uma reserva.
- A Uneed permitia um lançamento pendente por conta na via gratuita observada, pelo que um segundo produto espera até o primeiro passar.
- O Product Hunt confirmou uma data de lançamento e um fuso horário; isso confirma uma data, não um lugar na página inicial.
Nada disto é uma queixa. Os níveis gratuitos são moderados por pessoas com uma fila, e a fila é longa porque o nível é gratuito. O runbook manda o agente avisar-te sem rodeios de que muitos diretórios gratuitos demoram semanas, não dias, e nunca inventar o tempo de revisão de uma plataforma quando ela não o indica. O artigo sobre estados de submissão cobre o que o tracker regista em cada uma destas situações; este artigo é sobre o que fazes com esse conhecimento antes de começar.
Datas-alvo versus datas mínimas
Uma data-alvo é quando gostarias que as coisas acontecessem. Uma data mínima é o mais cedo que qualquer coisa pode acontecer. Os diretórios tornam os alvos pouco fiáveis e as datas mínimas baratas, por uma razão: controlas quando submetes e quando agendas, e mais nada.
Pensa no que acontece só com um alvo. Queres as listagens online na semana de 12 de outubro. O teu agente começa a 20 de setembro, porque as revisões levam semanas. A maioria dos diretórios gratuitos publica depois quando publica: alguns num dia, alguns no fim de outubro, alguns nunca. Mas as plataformas que te deixam escolher uma data — launch boards com lugares semanais, o Product Hunt com o calendário — aceitam de bom grado 28 de setembro se for o primeiro lugar livre que o agente vê, e agora a tua melhor plataforma de lançamento disparou antes de a página do produto, o changelog e o anúncio estarem prontos.
Com uma data mínima de 12 de outubro, o segundo problema desaparece. O agente pode na mesma submeter cedo aos diretórios moderados, porque submeter não é publicar e a data mínima não se aplica a isso. Não pode agendar nada antes de 12 de outubro, porque o tracker recusa. A fila de pendentes joga a teu favor: submissões feitas no fim de setembro começam a aterrar na semana-alvo ou depois, nunca antes.
Planear uma semana de lançamento coordenada
Este é o plano para que a data mínima foi desenhada. As datas são exemplos.
Semana −4: define a data mínima e faz o onboarding. Decide a data mais cedo em que algo pode ficar público. Põe-na no product.json durante o onboarding. Termina os factos do produto e o briefing de representação para que o agente tenha texto aprovado antes de tocar em qualquer formulário; uma listagem que fica online com a biografia errada do fundador é pior do que uma atrasada.
Semanas −4 a −2: submete aos diretórios moderados. Os que não têm calendário: filas de revisão, páginas de «aprovação pendente», estimativas de «em revisão». Submete-os primeiro porque são os mais lentos e não os consegues guiar. Regista cada resultado. Espera submitted_pending_review e queued, e espera que alguns fiquem lá para além da semana de lançamento; não faz mal, a data mínima nunca foi sobre eles.
Semanas −2 a −1: agenda as plataformas que aceitam uma data. Launch boards com lugares, o Product Hunt, tudo o que confirme uma data e um fuso horário. Dá ao agente a data mínima e um dia preferido; ele regista scheduled com a data confirmada pela plataforma, e o tracker recusa qualquer coisa anterior à data mínima. Onde um lugar está confirmado mas a aprovação continua pendente, a nota di-lo.
Semana de lançamento: verifica, depois publica. No dia, o agente abre cada listagem agendada antes de registar live; uma data num calendário não é prova de uma página pública. As comunidades — Hacker News, Indie Hackers, Peerlist e afins — são posts que escreves, não formulários, e o lugar delas é aqui, quando as listagens para que apontam existem.
Semanas +1 a +4: acompanha a fila. As submissões pendentes cuja janela de revisão indicada já passou são reverificadas, nunca resubmetidas para saltar a fila. As listagens que chegam tarde contam na mesma; chegam depois da data mínima, que é a única coisa que a data mínima prometeu.
O que a data mínima não faz
Não faz um diretório publicar mais depressa. Não se aplica aos estados submitted_pending_review e queued, porque esses são o relógio da plataforma. Não impede um diretório de publicar cedo uma listagem moderada se a submeteste cedo; se uma plataforma é conhecida por publicar de imediato na via gratuita, submete-a dentro da janela de lançamento, não antes. E não existe para produtos que já lançaram: a data mínima vazia é o valor por defeito, e o artigo sobre lançamentos sem orçamento descreve a abordagem gota a gota que serve um produto já no mercado.
Também não substitui o juízo sobre se deves submeter. Que plataformas merecem o esforço é uma pergunta à parte, respondida por produto com o método de evidência do ficheiro de prioridade, não por uma data.
Definir a data mínima na prática
Se corres o prompt de arranque, o agente pergunta durante o onboarding; responde com uma data ou diz «sem data mínima». Para a mudar mais tarde, edita earliest_launch_date no product.json do produto e avisa o agente, ou muda-a na vista de produto do painel local. As linhas scheduled existentes não são reescritas; a recusa aplica-se a registos novos, por isso se moveres a data mínima para depois de um lugar já confirmado, relê o tracker antes da próxima sessão do agente e decide se reagendas na plataforma.
Dois hábitos fazem isto funcionar. Confirma o fuso horário sempre que uma plataforma confirma uma data; o guia do Product Hunt existe em parte por causa disso. E trata um ecrã de agradecimento como o que é: não live, não scheduled, só o fim de um formulário.
A LaunchRepo inclui isto na licença de pagamento único: o onboarding que faz a pergunta, o tracker que impõe a resposta e 346 playbooks que sabem que plataformas aceitam uma data e quais simplesmente levam o seu tempo.
Fontes: ONBOARDING.md, RUNBOOK.md, DASHBOARD.md e CHANGELOG.md no repositório da LaunchRepo (versão de 15 de setembro de 2026); os guias públicos deste site, observados a 13 de setembro de 2026.