Same day rows, queues, and nine recorded visits

On 28 October 2026 the same 19 launch rows were already on one page. Two narrower pages regroup those rows. The third page lists nine referral visits recorded in one October week. They do not add sites.

• Same day product launch sites: 6 that listed us the day we tried
• Free product launch queues: 7 waits we saw in October 2026
• 9 referral visits we recorded in one October week

The full record stays on Where to launch a SaaS: 19 sites we tried.

Same day

Six listings were public the same day. BuildShipper, CLAPSTORM, Peerlist, BusinessHunt, Canopy Launch Directory, and Shipboard.

TinyLaunch was accepted the same day, and the launch date is November 23, 2026. That row is not one of the six. A wait written as within a day is also not the same day, so HereIsMySaaS and Startup Ranked stay on the full record and off this page.

Queue or scheduled date

Seven rows name a queue, a scheduled date, or a waiting line. LaunchRanked, PeerPush, TinyLaunch, DirArc, HUNT0, Uneed, and Launching Next.

GreenRocket says it launched 3 days after we submitted. That sentence does not name a queue, so GreenRocket is not in the seven. PeerPush names a free launch queue of about 97 days and does not name a calendar date. Uneed says the free waiting line was full and the launch was not scheduled. Launching Next names a free queue of about 4 months and does not name a date. Those three stay in the seven because the row names a queue or a waiting line. They are not the same thing as a named calendar date.

Nine visits

The third page uses the nine referral visits recorded for one October week. hereismysaas.com 2, alohafind.com 3, admin.webcatalog.io 2, thelaunchdirectory.com 1, and github.com 1. The total is 9.

The visible title counts visits. It does not call those visits users. The address keeps a phrase about users, and the heading does not repeat that phrase.

What the record actually contains

The October launch record is a small operational dataset, not a survey of launch directories. It contains 19 rows RadarMakers had tried by the time the related pages were prepared. Each row combines observations about a particular submission, such as whether a page appeared, what waiting language the site showed, or which link label was visible. Those observations have different meanings and should not be treated as interchangeable outcomes. A submission that was accepted is not necessarily live, a live link is not necessarily followed, and a referral visit is not proof of a new user.

The same source rows produce several narrower pages. Six records meet the wording rule for a public page appearing on the day of the attempt. Seven rows mention a queue, a scheduled date, or a waiting line. The nine referral visits belong to a separate analytics observation window from October 21 to 27. They are not a count of the 19 directories, and they should not be divided by 19 to suggest a conversion rate. The unit, source, and time window are different.

That distinction is the reason for keeping a source record and a definition beside each page. A derived page should make one answer easier to find without quietly changing the question. If a page says same day, it should say what event qualifies. If it says queue, it should tell a reader whether the queue means a numbered line, a named date, or simply a waiting state. If it reports visits, it must preserve the analytics unit and observation period.

Treat phrases as evidence, not categories from memory

The same day subset includes BuildShipper, CLAPSTORM, Peerlist, BusinessHunt, Canopy Launch Directory, and Shipboard. The inclusion rule refers to the observed public page or profile, not a launch event. This matters because platforms often let a maker publish a profile before a scheduled launch. A public listing can appear on one date while the launch is promoted on another. Calling both events a same day launch would make a clean looking table less accurate.

The row for TinyLaunch illustrates the boundary. The record says it was accepted the same day and names a later launch date of November 23, 2026. Accepted is not the same as public. It therefore belongs in a queue or scheduled-date analysis, not the same day public-page count. Keeping these fields separate makes it possible to answer a practical question without erasing an important distinction.

The queue subset names LaunchRanked, PeerPush, TinyLaunch, DirArc, HUNT0, Uneed, and Launching Next. This is a wording-based grouping that includes both named dates and waiting lines. It is not a measured average wait. PeerPush is described as a free queue of about 97 days, while Launching Next is described as a free queue of about four months. Uneed says the free waiting line was full and the launch was not scheduled. These phrases describe different states. A named duration, a calendar date, and a full unscheduled queue should remain visible as distinct observations.

GreenRocket is a useful negative case. Its note says it launched three days after submission, but does not say queue. It is left outside the seven queue rows. This does not say the listing was faster or slower than the others in a general sense. It simply records the inclusion rule. A reproducible filter needs such examples because otherwise future editors may add a row because it feels conceptually similar.

Build the page from a record, not a summary sentence

Begin with one row per attempted site and one stable identifier for the site. Store the exact observation date separately from prose such as same day or within a day. Keep the original wording or a faithful note that supports the derived label. Where the outcome can change later, add a checked-at date so a future reader can distinguish an old observation from a current status.

Use separate fields for submission status, public visibility, launch date, wait wording, link destination, and link relation. Do not collapse those into one launch result. A site can accept a submission while keeping its page private. A profile can be public before launch. The link can point to the product but carry a user-generated or nofollow relationship. A single status field would lose those facts and make later filtering unreliable.

When a classification comes from language, define the matching phrases and exclusions. For the queue group, a row is included because its note names a queue, date, or waiting line. For the same day group, the criterion is a public page or profile visible the day of the attempt. An approval with a later date fails the second rule. That explicit rule is more useful than a broad label because another person can reproduce it from the notes.

Before generating the page, have a second person review uncertain rows against the saved evidence. If the source page is gone or the record is ambiguous, use an unknown label instead of guessing. Keep the included and excluded reasons in the working dataset. The public page does not need every internal note, but the build should remain auditable. A correction should update the source row, every derived count, the chart, and any title that depends on that count in one change.

Do not confuse overlap with separate samples

Derived groups can overlap. A single row may describe a same day public profile and a queue for a later launch. That is not a contradiction: public availability and launch scheduling are separate dimensions. Therefore the six same day rows and seven queue rows cannot be added to claim 13 distinct directory sites. A row can appear in both groups, and other rows may appear in neither.

This is a common challenge in small research pages. Readers see two counts and naturally add them. A short note above the table should say whether groups overlap. A chart caption can repeat the condition. The design should not place the bars in a stacked total if the categories are not mutually exclusive. The overview chart here shows independent values and labels the shared 19-row source. It is a view of filters, not a partition.

The same care applies to referral data. The five recorded sources have counts of 2, 3, 2, 1, and 1, which sum to nine. A visit is an analytics event. It is not necessarily a distinct visitor, a qualified prospect, or a customer. The available source record does not prove that the visits were caused by the launch directories or that each person saw a product listing. The chart therefore reports the recorded source labels and counts only.

Show the date as part of the measurement

Counts without dates can become stale while still looking precise. The launch rows reflect the October 2026 research pass. The referral total refers specifically to October 21 through 27, 2026. The correct update is not to silently change a number when one listing moves. Recheck the relevant source, add the new observation date, and state whether the page is a snapshot or a maintained live report.

If a row later becomes public, the older same day result still describes what happened on the original attempt date. It should not be retroactively changed to suggest that the page was always live. A separate current status field can be updated, while the historical observation remains fixed. This makes the record useful for studying response times and avoids rewriting history as each site changes.

Date precision should match the underlying evidence. If the source note only says overnight, do not invent an exact hour. If it says within a day, do not translate it to a number of hours. If the platform published a date but not a time zone, avoid claims about a precise same-day interval unless the saved evidence establishes the time convention. The text label can still report the source wording and explain its limits.

Make each derived page answer a different question

The full directory page is the index into the record. It answers where RadarMakers submitted and what was observed for each row. A same day page answers which attempts resulted in a public page or profile during that day. A queue page answers which sites explicitly described a queue, scheduled date, or waiting state. A referral page answers which source labels appeared in one analytics report during a short date window.

Those pages should link back to the full record so a reader can inspect context. The links in the article carry a devto source and the same campaign value so visits from the article can be distinguished in the analytics. A link destination must match the claim beside it. The same day page supports the six named public outcomes. The queue page supports the seven language-based wait observations. The referral page supports the dated visit record. The full table supports all 19 observations.

Avoid a page that simply restates the same rows with a new keyword in the heading. A useful slice has a defined filter and a reason that filter helps someone make a decision. A founder may care about same day visibility when coordinating an announcement. A queue may matter when planning a launch calendar. Referral visits may help understand what a small directory experiment sent during one week, but cannot predict future acquisition. Put that limitation near the metric, not in a distant footnote.

Write captions that preserve the units

Use count nouns in chart titles. Six listings, seven queue-related rows, and nine visits say what the data contains. A title such as six successful launches would add an interpretation not established by the record. Avoid a percentage if the denominator is not a meaningful population. Six of 19 can be calculated as a fraction, but it describes the share of this hand-assembled record matching a filter, not the chance that any directory will publish a new listing the same day.

The overview chart uses counts, not percentages, and explicitly says the groups can overlap. The referral chart uses visits for its axis and prints the five source labels. Its source note gives the date window and says the values are visits rather than users. These small decisions keep a visual from overstating a sparse dataset. When there are only a handful of observations, show the exact values rather than drawing a smooth trend line.

Choose readable labels and alt text. A chart should not rely on color alone to distinguish rows. A text table in the article can provide the same values to someone who cannot inspect the image. Alt text should name the chart purpose and the important data without repeating the entire source citation. Put the full source and method in visible text under the image as well as inside the graphic when practical.

Decide what to measure on the next research pass

The current record is enough to show why separate outcome fields matter, but it is not enough to compare platform performance. A future pass can make that comparison more useful by writing down the submission date, the date the first public page appeared, the scheduled launch date, the link target, the link relation, and a dated follow-up check. It should also save the page or a screenshot where permitted, so a later review can verify what the result meant.

Keep attempts that did not produce a listing. Removing failed or pending submissions creates survivorship bias. Record the reason when a platform rejects a submission or asks for a paid placement, but do not infer a reason where no response arrived. A pending status is a valid observation. It is also useful to distinguish a dead domain from a temporary outage by recording the check date and whether a second independent resolution attempt was made.

For analytics, decide what counts as a referral visit and what filters apply before collecting the next period. Exclude internal checks if a reliable method exists, and document bot filtering. Do not name a unique visitor count unless the analytics system reports that field and the methodology supports it. Keep one defined date range, then compare ranges only if the collection settings are the same. A small report should be cautious, but it can still be transparent and replicable.

A short audit before publishing a data slice

Check the source file and count the rows. Check each filter against its written rule, including the rows that almost qualify. Confirm that the chart and page use the same values. Read each caption for unsupported words such as successful, popular, or best. Confirm that a dated measurement includes its date and unit. Review internal links so each label opens the page that answers the linked question.

Then ask what a reader could reasonably conclude. If the data does not establish a general success rate, say so. If categories overlap, disclose that. If the analytics measure visits, do not call them people. If a queue duration comes from one platform statement, preserve its approximate wording and do not present it as a platform-wide service level. A careful page can still be interesting because it reveals the actual process and its limits.

The value of a small dataset is not that it can settle every launch decision. Its value is that it lets another maker inspect concrete outcomes, ask better questions, and plan a follow-up measurement. Keeping the row-level source, a precise definition, and a visible date turns a private spreadsheet into a modest but useful field note.

Sources and record notes

The figures in this article come from the October 2026 RadarMakers launch record of 19 rows and the analytics source breakdown for October 21 to 27, 2026. The page copies of those records are Where to launch a SaaS, same day product launch sites, free product launch queues, and the one-week referral visit record. Each page is a view of the underlying observations, not a second dataset.

Sources

• RadarMakers October 2026 launch log, 19 rows, represented by the linked full record and dated subset pages.
• RadarMakers referral analytics note, October 21 to 27, 2026, shown on the linked visit report.

Chart sources and units are printed inside both images. Counts are copied from the recorded rows and visit source breakdown. No estimates are plotted.

Do not merge a visit report with a link inventory

A source can provide a followed link and receive no measurable visit during a chosen window, or provide another link type and still generate a visit. The link relation and analytics source are different fields. Keep them separate in a report and attach a date range to the visit count. The October 21 to 27 total describes nine recorded visits, not nine distinct people or nine conversions.

When a source label is missing or ambiguous, preserve that uncertainty. Do not distribute unattributed visits across the platform rows just to complete a table. A future event can be measured with a tagged URL, but it should not be retroactively assigned to an older link without evidence.

Name the attribution window beside every total

A visitor total without dates is difficult to compare. State the start and end dates, the analytics source, and whether the metric counts visits, sessions, or people. In this record, the nine is a visit total for October 21 to 27. It does not mean nine unique people. It is also separate from the 19 rows in the submission inventory, because the source report does not join every visit to every listing.

If a chart groups visits by a source string, label the value as visits and preserve any missing source separately. Do not assign a visit to a launch directory based only on a similar name. Analytics can lose a referrer during redirects or sharing, and the available evidence does not restore that missing attribution.