LaunchRepoThe first question the toolkit’s onboarding asks about timing is not “when do you want to launch?” but “is there a date before which nothing should go public?” Those are different questions, and the difference is the subject of this article. The short version: directory submissions do not go live when you submit them, they go live when the directory gets around to it, and if you want a launch week rather than a launch smear you need a floor, not a target.
The feature, in one paragraph
Since the 15 September 2026 release, product.json has a field called earliest_launch_date. Blank means no floor. If it holds a date, the tracker’s record.py refuses to mark any platform as scheduled with a launch date earlier than it, and it refuses scheduled without a --launch-date at all. Onboarding asks for the value up front, and the local dashboard shows the floor next to the scheduled state. That is the entire feature: one field, one refusal, one question asked before anything is submitted. The changelog has the release note.
It is small on purpose. It does not delay submissions, because it cannot; the agent does not decide when a directory publishes. What it does is stop the one thing that is under your control from going wrong: an agent confirming a launch date on a platform that offers a calendar, for a week you did not want.
Why free directories publish later than you think
If you have never submitted a product to a directory on its free route, the timelines are surprising. From the public field guides on this site, all observed in September 2026:
- SaaSHub produced a publicly reachable page immediately after submission, labelled Pending approval. Reachable is not accepted; the tracker keeps
submitted_pending_reviewuntil the label goes away. - PitchWall accepted the submission into Under Review with a review estimate exceeding 30 days.
- TinyLaunch offered a future weekly slot on its standard path, then left approval outstanding after the date was chosen: scheduled, with a qualification.
- Uneed allowed one pending launch per account on the observed free route, so a second product waits until the first has cleared.
- Product Hunt confirmed a launch date and time zone; that confirms a date, not homepage placement.
None of those is a complaint. Free tiers are moderated by people with a queue, and the queue is long because the tier is free. The runbook tells the agent to warn you plainly that many free-tier directories take weeks, not days, and to never invent a platform’s review time when the platform does not state one. The submission-states article covers what the tracker records in each of these situations; this article is about what you do with that knowledge before you start.
Target dates versus floors
A target date is when you would like things to happen. A floor is the earliest anything is allowed to happen. Directories make targets unreliable and floors cheap, for one reason: you control when you submit and when you schedule, and nothing else.
Consider what happens with a target only. You want listings live in the week of 12 October. Your agent starts on 20 September, because reviews take weeks. Most free directories then publish whenever they publish: some in a day, some in late October, some never. But the platforms that let you pick a date — launch boards with weekly slots, Product Hunt with its calendar — will happily accept 28 September if that is the first free slot the agent sees, and now your best launch platform has fired before your product page, your changelog and your announcement are ready.
With a floor of 12 October, the second problem disappears. The agent can still submit early to the moderated directories, because submission is not publication and the floor does not apply to it. It cannot schedule anything before 12 October, because the tracker refuses. The pending queue works in your favour: submissions filed in late September start landing in the target week or after, never before.
Planning a coordinated launch week
Here is the plan the floor is designed for. Dates are examples.
Week −4: set the floor and onboard. Decide the earliest date anything may go public. Put it in product.json during onboarding. Finish the product facts and the representation briefing so the agent has approved text before it touches any form; a listing that goes live with the wrong founder bio is worse than a late one.
Weeks −4 to −2: submit to moderated directories. The ones without a calendar: review queues, “pending approval” pages, “under review” estimates. Submit them first because they are slowest and you cannot steer them. Record every outcome. Expect submitted_pending_review and queued, and expect some to sit there past the launch week; that is fine, the floor was never about them.
Weeks −2 to −1: schedule the platforms that take a date. Launch boards with slots, Product Hunt, anything that confirms a date and time zone. Give the agent the floor and a preferred day; it records scheduled with the platform’s confirmed date, and the tracker will refuse anything earlier than the floor. Where a slot is confirmed but approval is still pending, the note says so.
Launch week: verify, then post. On the day, the agent opens each scheduled listing before recording live; a date on a calendar is not proof of a public page. Communities — Hacker News, Indie Hackers, Peerlist and the like — are posts you write, not forms, and they belong here, when the listings they point at exist.
Weeks +1 to +4: follow up the queue. Pending submissions whose stated review window has elapsed get rechecked, never resubmitted to jump the line. Listings that arrive late still count; they arrive after the floor, which is the only thing the floor promised.
What the floor does not do
It does not make a directory publish faster. It does not apply to the submitted_pending_review and queued states, because those are the platform’s clock. It does not prevent a directory from publishing a moderated listing early if you submitted it early; if a platform is known to publish immediately on the free route, submit it inside the launch window, not before. And it does not exist for products that have already launched: a blank floor is the default, and the zero-budget launch article describes the trickle approach that suits a product already in the market.
It also does not replace judgement about whether to submit. Which platforms deserve the effort is a separate question, answered per product with the evidence method in the priority file, not by a date.
Setting the floor in practice
If you run the start prompt the agent asks during onboarding; answer with a date or say “no floor”. To change it later, edit earliest_launch_date in the product’s product.json and tell the agent, or change it in the local dashboard’s product view. Existing scheduled rows are not rewritten; the refusal applies to new records, so if you move the floor later than an already confirmed slot, re-read the tracker before the agent’s next session and decide whether to reschedule on the platform.
Two habits make this work. Confirm the time zone whenever a platform confirms a date; the Product Hunt field guide exists partly because of that. And treat a thank-you screen as what it is: not live, not scheduled, just the end of a form.
LaunchRepo ships this as part of the one-time licence: the onboarding that asks the question, the tracker that enforces the answer, and 346 playbooks that know which platforms take a date and which just take their time.
Sources: ONBOARDING.md, RUNBOOK.md, DASHBOARD.md and CHANGELOG.md in the LaunchRepo repository (release of 15 September 2026); the public field guides on this site, observed 13 September 2026.