DEV Community: Devin D

Show HN, Product Hunt and BetaList before launch: what each one accepts

Devin D — Wed, 14 Oct 2026 14:52:05 +0000

A common plan for launching a side project: put up a waitlist page, post it to Show HN, Product Hunt and BetaList, and let the signups come in. Two of those three have rules that get in the way before launch, and the third changed how pre-launch works in 2025.

I make a waitlist tool, Waitlister, and one of the rules below applies to pages built with it.

Show HN: wait until there's something to try

Show HN is for things people can try. The Show HN guidelines list sign-up pages as off-topic, and a waitlist page is a sign-up page. Hold the post until people can use what you built.

Product Hunt: Coming Soon pages are gone, so schedule instead

Product Hunt retired its "Coming Soon" pages on August 28, 2025, so older launch guides that tell you to set one up are out of date. What you can do now is schedule the launch up to 30 days ahead. People can follow the product and get notified when it goes live.

Launches tend to go better with supporters who already know it's coming. So Product Hunt amplifies a list you already have, and it fits near the end of pre-launch.

BetaList: your own domain, and a page that doesn't look like a template

BetaList features startups that haven't launched yet, so it's the one of the three where a waitlist page fits. It asks for a custom-designed landing page with a signup form on your own domain, and it turns down template pages and free subdomains.

This is the rule that applies to Waitlister pages. A hosted waitlist page on the tool's own domain (on Waitlister that's waitlister.me/p/your-page) won't qualify: BetaList requires your own domain, and its guidelines also turn down pages hosted by landing-page services. The route that fits is a page you design on your own domain, with the signup form embedded in it. On Waitlister, the embeddable form is on every plan, including free.

Before you qualify for any of them

All three do more when people are already paying attention. Getting that attention costs time more than money, and three things work with no audience:

Write to people who have the problem, one message per person. Ask what they make of the problem before you bring up the waitlist. Some will join, and the replies tell you whether the problem bothers them as much as it bothers you.
Answer questions where your future users ask for help, often a subreddit or a forum for their trade. Read the rules first, since many communities restrict self-promotion, especially from new accounts.
Get featured where your users already read or listen. A niche newsletter whose readers are mostly your kind of user usually does more than a big general one.

If your users are developers, building in public fits too, though the following grows slowly, over months. Build-in-public posts mostly reach other builders. That's the right crowd for a developer tool, and a weak one for, say, scheduling software for dentists.

I wrote up twelve pre-launch strategies, sorted by how much audience each one needs, here: Pre-launch marketing strategies, sorted by audience.

Waitlist referral rewards: points, webhooks, and not paying self-referrers

Devin D — Sat, 26 Sep 2026 17:55:33 +0000

I make Waitlister, a waitlist tool, so the examples here use it. The design carries over to most referral waitlists.

A referral waitlist fits in one sentence: every subscriber gets a unique link, a signup through that link earns the referrer points, the list is ranked by points, and everyone can see their position. A waitlist tool can track all of that. The reward is where your own code usually comes in, because what you hand out, and when, is up to you.

Why points

A referral count measures one action. Points let you weight several. In Waitlister the defaults are 50 points for joining, 30 for a successful referral and 5 for following a social account from the thank-you page. You can change any of them, including to zero.

Points also cover actions the tool can't see. On the Growth plan, the update subscriber endpoint can set a subscriber's points, so completing a survey, joining your Discord or testing a build can move someone up the list.

Rewards live in your backend

The tool tracks points. Fulfillment, whether that's a discount code, beta access or a T-shirt, is yours. Two webhook events cover it:

waitlist.referral_completed fires when a referral is credited. The payload has the referrer (id, email, points, total_referrals) and points_earned.
waitlist.milestone_reached fires when a signup or a credited referral takes a subscriber's points across a threshold you configure. It carries milestone.points and the subscriber's previous_points.

Milestones are set in points. With the defaults, a reward at five referrals is a threshold of 200 points: 50 for joining plus 5 × 30, assuming the subscriber hasn't earned points any other way. Points set through the API or earned from a social follow don't trigger the milestone check, so if they carry someone past a threshold, that subscriber doesn't get the event for it. If you award points for custom actions, check thresholds in your own code too. For rewards tied to a referral count, referral_completed already carries total_referrals.

A minimal Express handler:

const crypto = require('crypto')
const express = require('express')
const app = express()

// Keep the raw body: the signature is computed over the exact bytes sent
app.use(express.json({ verify: (req, res, buf) => { req.rawBody = buf } }))

function isSigned(req, secret) {
  if (!secret || !req.rawBody) return false
  const received = Buffer.from(req.get('X-Webhook-Signature') || '')
  const expected = Buffer.from('sha256=' +
    crypto.createHmac('sha256', secret).update(req.rawBody).digest('hex'))
  // timingSafeEqual throws if the byte lengths differ, so check first
  return received.length === expected.length &&
    crypto.timingSafeEqual(received, expected)
}

app.post('/webhooks/waitlister', async (req, res) => {
  if (!isSigned(req, process.env.WAITLISTER_WEBHOOK_SECRET)) return res.sendStatus(401)

  const { event, data } = req.body
  if (event === 'waitlist.milestone_reached') {
    // Pay each (subscriber, threshold) pair once, even if the event arrives again
    await grantRewardOnce(data.subscriber.id, data.milestone.points, data.subscriber.email)
  }
  res.sendStatus(200)
})

grantRewardOnce is yours to write: record each subscriber and threshold pair you pay out (a unique key on the pair stops two copies of one event from both paying), and queue anything slow, like emailing a code, so the handler responds quickly. A delivery times out after 15 seconds. Set a secret on the webhook so requests arrive signed; without one there's no signature header and this handler rejects everything. Webhooks are on the Growth plan; the referral program itself starts at Launch.

Not paying self-referrers

The obvious attack is one person, ten throwaway inboxes, and the top of the leaderboard. Waitlister scores each referred signup on device fingerprint, IP address, normalized email (Gmail dots and +suffixes stripped) and how fast referrals arrive, and it checks against known disposable email domains. Signups you create through the API skip these checks unless you forward client signals: send the visitor's IP as metadata.client_ip (it must be IPv4), plus a device fingerprint if you have one. Without the visitor's IP, the IP Waitlister sees is your server's. The protection level runs from off to strict.

From your code's side, a flagged referral looks like this. The new signup still joins the list. The referrer gets no points, no referral_completed event fires, and no milestone gets crossed, so your reward code never sees it. Nothing tells the person gaming it why.

Reward design still does more than detection. Rewards that pay out after a delay, or only to confirmed email addresses, remove most of the reason to cheat before anything has to be caught. With double opt-in on, a subscriber joins the list only after confirming their address.

Which reward to run

Pick the reward first, since everything above follows from it. A place in line needs no prize budget and works when getting in early is worth something by itself. A public leaderboard suits audiences who compete and share in public. Rewards at set thresholds work if the first one is easy to reach. A prize draw brings the most signups and the least qualified list. You can move between position and leaderboard later without resetting anything, because both run on the same points. Taking a prize away after people joined for it is the change to avoid.

I wrote up the full setup, including the build order and what to put on the thank-you page, here: How to add a referral program to your waitlist.

Adding a waitlist to your app: four ways to wire it up, and what breaks the first signup

Devin D — Fri, 25 Sep 2026 11:51:24 +0000

I make Waitlister, a waitlist tool, so the examples here use it. The shape carries over to most tools.

The signup part of a waitlist is small. The decision that matters is where the signup lives, because that decides how much code you write and what can go wrong on your first test.

The four options

Option	Code	Good for
Hosted page	none	no site yet, or you want something live today
Embedded form	a snippet or plugin	an existing Framer, Webflow, WordPress or Shopify site
Your own HTML form	one form tag	full control over markup and styling
API or SDK	a few lines	signup inside your app, or a custom flow

If your site already gets traffic, put the signup there. If the site doesn't exist yet, a hosted page gets you live fastest. The last two are the ones that involve code.

Your own HTML form

Any form can post straight to the waitlist:

<form action="https://waitlister.me/s/YOUR_WAITLIST_KEY" method="POST">
  <input type="email" name="email" required placeholder="you@example.com" />
  <button type="submit">Join the waitlist</button>
</form>

On submit, the subscriber is redirected to a hosted thank-you page with their queue position and a referral link, so you don't have to build one.

Before you test it, add your site's domain to the waitlist's whitelisted domains (waitlist → Settings). Until you do, the endpoint rejects submissions from that site with a 403.

Waitlister's CAPTCHA doesn't cover a form you built yourself, so bot protection on this route is yours to handle.

The API or SDK

npm install waitlister

import { Waitlister } from 'waitlister'

// Server-side only: the key must not reach the browser
const wl = new Waitlister({ accountKey: 'wl_acct_…', waitlistKey: 'YOUR_WAITLIST_KEY' })
const result = await wl.signUp({ email: 'user@example.com' })
// result.position, result.referral_code, result.redirect_url

There are two kinds of key, and the difference matters:

Account API keys (wl_acct_…, Settings → API keys) work on every plan, including free, with lower rate limits on the smaller plans. One key covers every waitlist you own, and it can also create waitlists (up to your plan's waitlist limit), which is handy in setup scripts and agent workflows.
Per-waitlist keys (passed as apiKey) need the Growth plan, and so does reading or changing subscriber records over the API.

On a plan without access, the SDK throws a typed PlanError instead of failing silently. If you'd rather not handle a key at all, signUpViaForm from the same package posts to the public form endpoint and gives you the hosted thank-you page URL to redirect to. The full schema is in the OpenAPI spec.

What breaks the first test signup

The domain isn't whitelisted (HTML form route): submissions return 403 until it is.
You tested with a fake address. Waitlister validates deliverability at signup, so test@example.com is rejected. Use a real address you control.
You re-tested with the same address. Signing up again with an address that's already on the list doesn't create a new signup, so no welcome email goes out. Delete the first signup on the Submissions page, or use a different address (a +alias works).

The part that isn't code

Getting the signup, thank-you page and welcome email working fits in an afternoon. Whether the list turns into customers depends on two things no SDK handles.

The first is where visitors come from. Subscribers = visitors × the share who sign up, so if you want 300 people and one visitor in five signs up, you need 1,500 visitors. (That rate is made up for the arithmetic; use your own once you have some traffic.) Plan where those visitors will come from before you polish the page.

The second is what you send people while they wait. Set up the welcome email before any traffic arrives and send a short update every week or two, or the list tends to go cold before launch day.

I wrote up the whole process, including the welcome email I'd use and how to protect the list from fake signups, here: How to create a waitlist, step by step.

GEO vs SEO: what changed, what didn't, and two checks to run today

Devin D — Fri, 25 Sep 2026 09:19:45 +0000

GEO vs SEO comes down to where you show up. SEO gets your page ranked in a list of links. GEO, short for generative engine optimization, gets your brand named or your page cited inside an answer that an AI system writes, such as Google's AI Overviews or ChatGPT. GEO builds on SEO and doesn't replace it. Most of the work is shared, and a few parts are new.

Search "geo vs seo" on Google and you'll likely see an AI Overview before the first link. When I checked on 18 September 2026 (US, desktop), it cited 12 pages. Six of them ranked outside the top ten, and three weren't in the top 19. That's one check on one day, and overviews vary, but it matches the larger studies below.

The pages that rank for this search agree on the verdict: you need both. I agree. They skip the harder question of which GEO advice has evidence behind it, so this guide spends its time there.

GEO vs SEO: the differences at a glance

	SEO	GEO
Where you appear	A ranked list of links	Inside a written answer, as a named brand or a cited source
What gets chosen	A page	A passage from a page, plus brand names gathered from many pages
What builds authority	Links to your site	Mentions of your brand across the web, linked or not. So far that's a correlation
What the query looks like	A few keywords	A full question, which the engine splits into several searches
Who fetches your pages	Googlebot, which runs JavaScript	Googlebot for Google's AI features, plus AI crawlers such as OAI-SearchBot and PerplexityBot, which mostly don't
Where it searches	Google's index	It depends on the assistant: Google's index for AI Overviews and AI Mode, other search backends for ChatGPT, Perplexity and Claude
How you measure it	A position that mostly holds between checks	A rate across repeated runs, because one prompt gives different answers each time

GEO vs SEO vs AEO: what the acronyms mean

Four terms cover most of what you'll read:

SEO, search engine optimization: ranking pages in a list of results.
GEO, generative engine optimization: getting into answers that an AI system writes from several sources. It's the academic term, from a research paper covered below.
AEO, answer engine optimization: being the direct answer on any surface that gives one. It was in use by 2018, when it meant voice assistants and featured snippets.
LLMO, large language model optimization: shaping how the model itself describes your brand, including what it absorbed in training and repeats without searching.

You'll also see AIO, which usually means Google's AI Overviews and sometimes means "AI optimization".

The terms overlap. Wikipedia's GEO article says no consensus definition distinguishing them had been established in the academic literature as of early 2026, and that they're used interchangeably in practice. Its "answer engine optimization" page now redirects to the GEO article. In this guide, GEO means the whole job: getting named and cited in AI answers.

What changed

Mentions count for more than links

Ahrefs studied 75,000 brands in May 2025 to see what goes along with being named in AI Overviews. Branded web mentions had a correlation of 0.664 with AI Overview visibility, where 1 would be a perfect match. Backlinks had 0.218. A mention counted whether or not it carried a link.

A December 2025 follow-up added ChatGPT and AI Mode and found the same pattern: web mentions between 0.66 and 0.71, mentions on YouTube strongest at about 0.74, and link metrics "very weak".

Ahrefs flags the limit itself: correlation isn't causation. Well-known brands collect both mentions and AI visibility. Still, the pattern makes sense: an AI system reads many pages and summarises them, so what those pages say about you counts for more than which of them link to you.

One question becomes several searches

Google calls it query fan-out: AI Mode breaks your question into subtopics and runs many searches at once on your behalf. Your page can be cited for a sub-question nobody typed.

So ranking for the main keyword matters less than it did. In July 2025, Ahrefs found that 76% of the pages cited in AI Overviews ranked in Google's top 10 for the same query. Its March 2026 re-run found 38%, with 31% of cited pages ranking outside the top 100.

Between the two studies, Ahrefs improved its citation tracking and AI Overviews moved to Gemini 3, so don't read the drop as exact. Ahrefs' read is that AI Overviews now lean less on the results for the query itself and more on the results for the fan-out queries. That argues for covering a topic's follow-up questions on one solid page over building one thin page per keyword.

Most AI crawlers don't run JavaScript

Vercel and MERJ analysed crawler traffic across Vercel's network in December 2024. None of the major AI crawlers rendered JavaScript, and that included the crawlers from OpenAI, Anthropic, Meta, ByteDance and Perplexity. Googlebot does render pages.

So if your content only appears after JavaScript runs, Google sees your page and ChatGPT may see an empty shell. Nothing errors and your Google rankings don't move, so you won't notice unless you look. The study is nearly two years old and covers one network, but I haven't seen newer data that contradicts it.

Each assistant searches somewhere different

A good Google ranking doesn't carry over to the other assistants on its own. AI Overviews and AI Mode draw on Google's index. ChatGPT search has its own crawler, OAI-SearchBot. When Seer Interactive compared ChatGPT search citations with search results in February 2025, 87% matched a page in Bing's top 20 for the same question, and 56% matched Google. Seer calls its 100-query sample directional. Perplexity runs its own crawler as well.

Answers change from run to run

Ask an AI system the same question twice and you can get two different sets of brands. So being named in an answer is a rate: across 30 runs, you appear in some share of them. A result should read like 32% (24–41%), the share plus the range the sample supports.

One run of one prompt tells you close to nothing. A single "visibility score" with no range hides that.

What didn't change: Google says it's still SEO

Google publishes a guide called Optimizing your website for generative AI features on Google Search. It answers the GEO question in one sentence:

From Google Search's perspective, optimizing for generative AI search is optimizing for the search experience, and thus still SEO.

The same guide lists things you can ignore for Google Search. One is llms.txt and similar special files, because "Google Search itself doesn't use them". Another is overfocusing on schema: structured data "isn't required for generative AI search, and there's no special schema.org markup you need to add."

Google is speaking for Google Search only, which covers AI Overviews and AI Mode. ChatGPT, Perplexity and Claude find their sources in other ways, and most of the differences above come from there.

Is GEO replacing SEO?

No. GEO depends on SEO. AI systems answer by running searches and reading what they find, so a page that search engines can't crawl, index and retrieve has little chance of being cited. GEO adds a short list of jobs that a classic SEO plan doesn't include.

The skeptics are right about a lot. Much of what gets sold as GEO is technical SEO plus clear writing: direct answers, tables, FAQ sections. Good editorial teams have done that since featured snippets arrived, and a new acronym is a convenient way to sell it again.

Three jobs are new, though:

Checking that AI crawlers can reach and read your pages.
Earning mentions on the pages that AI answers draw from, linked or not.
Measuring with repeated prompt runs and ranges, since there's no stable position to track.

Most of your effort still belongs to SEO.

The "up to 40%" statistic comes from a lab test

One number keeps turning up in GEO pitches: GEO methods can "boost visibility by up to 40%". It comes from the paper that coined the term, by researchers at IIT Delhi and Princeton, published at the KDD conference in 2024.

The authors built their own answer engine. For each of 1,000 test queries, it took the top five Google results and had GPT-3.5 write an answer that cited them. GPT-3.5 then rewrote one of the five sources using one of nine methods, the engine answered again, and the authors measured how much more of the answer drew on the rewritten source.

They report gains of 30 to 40% for their best methods: adding quotations, adding statistics and citing sources. The 40% is the single best case, quotations. Keyword stuffing offered "little to no improvement".

Three reasons to hold the figure loosely:

The engine was the authors' own. No live AI search product produced the headline number.
Five sources competed for one answer, so a gain for one is a loss for the others, and relative gains look large.
GPT-3.5 wrote the rewrites, and the prompts in the authors' published code let it invent what it added. The statistics prompt reads "Add positive, compelling statistics (even if hypothetical)". The test shows that text shaped like evidence gets cited more. It didn't compare real evidence with invented evidence.

The authors also ran 200 queries through Perplexity, uploading the source texts as files because Perplexity wouldn't let them choose its sources. Quotations and statistics still helped there, and citing sources gave mixed results.

The direction is worth keeping: pages with concrete, attributable facts were easier for a model to cite. So publish your real numbers. The 40% describes the authors' test setup and doesn't predict what you would gain.

What to do first

In order of certainty. The first two are pass or fail, and you can check both today.

1. Check that AI crawlers are allowed in

Open yoursite.com/robots.txt and look for rules naming OAI-SearchBot, ChatGPT-User or PerplexityBot. OpenAI documents its crawlers separately: GPTBot collects content that may be used for training, and OAI-SearchBot surfaces sites in ChatGPT's search results. A site that blocks the second one to stay out of training data has blocked the wrong bot. If you find a block you didn't intend, remove that rule.

Then check your CDN or firewall. A bot rule there can refuse AI crawlers whatever robots.txt says. Cloudflare, for one, has a setting that blocks AI bots, and it's easy to forget who switched it on.

If you use Search Console, check one more switch. Since 31 August 2026 every property has a Search generative AI control, and a site has to be included there to appear in Google's AI features. Include is the default. Confirm nobody changed it.

2. Check that your content is in the raw HTML

Open a key page, view its source (Ctrl+U, or Cmd+Option+U on a Mac) and search for a sentence you can see on the page. If the sentence isn't in the source, a crawler that doesn't run JavaScript can't see it either.

For a number, run this in PowerShell. It ships with Windows. On macOS or Linux, install PowerShell and start it with pwsh.

$url  = "https://example.com/pricing"
$html = (Invoke-WebRequest -Uri $url -UseBasicParsing).Content
$text = $html -replace '(?s)<script.*?</script>|<style.*?</style>', '' -replace '<[^>]+>', ' ' -replace '\s+', ' '
"{0} characters of visible text in the raw HTML" -f $text.Trim().Length

A full page returns thousands of characters. A few hundred, on a page that looks complete in your browser, means the content arrives by JavaScript. The fix is server-side rendering or static generation, and it comes before everything else on this list.

3. Keep doing SEO

AI systems find their sources by searching, so being crawlable, indexed and useful still comes first.

4. Find the pages that answers cite, and get onto them

Ask ChatGPT and Google the questions your buyers ask, several times each, and note which sources keep coming back. When I checked Google for 11 buying keywords in the software category I work in, in September 2026, one search each, 49 of the 84 citations in its AI Overviews went to pages owned by vendors in the category, and YouTube videos were cited in 8 of the 11 answers. Yours will differ, so look. The sources that keep coming back are your outreach list.

5. Write passages that can be lifted

Put the question in a heading and answer it in the first two or three sentences underneath. Use real numbers, names and dates. Adding statistics is the part the GEO paper tested. The rest is ordinary good editing.

6. Measure with repeated runs

Pick 20 to 50 questions your buyers ask. Run each one several times on each engine. Track how often you're named, as a rate with a range, and wait for a change bigger than the run-to-run noise before you credit any fix.

What can wait

Schema markup as an AI-citation tactic, and llms.txt. Google says neither is needed for its AI features. Keep schema for rich results, where it does work.

Two questions that come up

Is SEO dead because of AI?

No. Clicks do drop when an AI summary is on the page: Pew Research tracked 900 US adults in March 2025 and found they clicked a search result on 8% of visits when an AI summary appeared, against 15% when it didn't. But AI answers are assembled from pages that search engines can crawl, index and retrieve. Most of the work that gets you found in search also gets you into the answer.

Does schema markup or llms.txt help with GEO?

For Google's AI features, Google says neither is needed: structured data "isn't required for generative AI search", and Google Search doesn't use llms.txt. When Ahrefs tracked 1,885 already-cited pages that added schema, their AI citations barely moved. Schema still earns rich results in classic search, so keep it for that. llms.txt is useful for pointing coding agents at developer documentation, which is a different job from search visibility.

I checked 15 AI search guides

Devin D — Mon, 21 Sep 2026 11:05:34 +0000

I searched Google for three things people ask about AI search: "llm seo", "ai visibility" and "how to rank in chatgpt". For each search I took the first five guides.

We were writing guides on the same three topics for Shruwd (https://shruwd.io/), the tool we are building, so I checked the 15 on a few points our own guides would cover.

Four checks came out of it that you can run on any AI search guide before you act on it.

1. Is there a source behind the number?

Each of the five "llm seo" guides recommends schema markup at least once. Two also say schema is on close to every page ChatGPT cites.
Neither links a source.

A matched study has tested if adding schema brings more citations to pages that already get some. Ahrefs followed 1,885 such pages as their owners added schema from August 2025 to March 2026, and compared them with 4,000 control pages. The effect on citations in ChatGPT and Google's AI Mode, in Ahrefs' words: "Statistically indistinguishable from zero."

Even if the two guides are right, that alone wouldn't show if schema actually helps. Sites that look after their SEO usually add it, so it would turn up on cited pages either way.

So I wouldn't put schema at the centre of an AI search plan on the strength of an unsourced number.

2. Does the number come with a range?

Three of the five "ai visibility" guides recommend tracking a single visibility score, and none of the five shows a range for any number, or says how big a change has to be before you trust it.

At the end of 2025, 600 volunteers ran 12 prompts through ChatGPT, Claude and Google's AI for a SparkToro and Gumshoe study, 2,961 runs in total. For ChatGPT and Google's AI, the authors put the chance of two responses naming the same list of brands at under 1 in 100.

A number from one check can move a lot while nothing about your site changes. If you're named in 10 of 30 answers, the 95% range for your real rate is roughly 19% to 51%.

Semrush's head of organic and AI visibility, Sergei Rogulin, writes that a share of voice "that swings between 20% and 40% over a day is normal". His advice is to report it with a margin.

Before you react to a change in any AI visibility number, ask how many answers it came from. With 30, a swing of 10 points can be noise.

3. Does it cite the vendor's own documentation?

One of the five "how to rank in chatgpt" guides links OpenAI's crawler documentation, and none of them tells you what to make of ChatGPT-User in your logs. OpenAi's page describes several crawlers and three are worth telling apart:

OAI-SearchBot gathers pages for ChatGPT's search. Block it and your site "will not be shown in ChatGPT search answers, though can still appear as navigational links."
ChatGPT-User visits a page on behalf of someone using ChatGPT. For that reason, OpenAI says robots.txt rules "may not apply" to it.
GPTBot crawls content OpenAI may use to train its models, and OpenAI's page doesn't tie it to search.

My reading of a ChatGPT-User visit: someone using ChatGPT asked for something that needed that page, probably at that moment. That makes the visit one of the few traces a ChatGPT answer leaves in a server log.

Two things to check on your own site:

A robots.txt rule meant for GPTBot shouldn't also block OAI-SearchBot.
Before you count a ChatGPT-User visit check its IP against the ranges OpenAI publishes. Any request can call itself ChatGPT-User.

4. Is the check dated?

AI answers can shift in weeks. In Semrush's tracking, the share of ChatGPT responses citing Reddit dropped from nearly six in ten in early August 2025 to about one in ten by mid September.
A guide with no date on its checks gives you no way to tell whether they still hold.

Limits of this check

This was one day (18 September 2026), three searches and 15 pages. I saved each page's HTML and searched its text for the points above, rather than reading each page in full. I wouldn't generalise from it.

We wrote our own guides on the same three topics after these checks:

LLM SEO: https://shruwd.io/blog/llm-seo
AI visibility: https://shruwd.io/blog/ai-visibility
How to rank in ChatGPT: https://shruwd.io/blog/how-to-rank-in-chatgpt

Pre-launch waitlist tools in 2026: why I'd pick Waitlister, and when I wouldn't

Devin D — Fri, 14 Aug 2026 14:50:09 +0000

This is guide on selecting a waitlist tool for your pre-launch campaign. The prices and plan limits are all here too, so you can check my reasoning instead of taking my word for it.

Updated October 10, 2026. I re-checked every price below on the vendor's own page. Since the first version, LaunchList has moved to subscriptions and GrowSurf now has a free plan for affiliate programs, so parts of the old post were wrong.

Short version

For most pre-launch founders, I'd pick Waitlister. Here's why, and all of it is on the pricing page:

The free plan has no clock. 100 subscribers, a hosted landing page or an embeddable form, and CSV export. No card.
$19 a month gets you unlimited subscribers. The same plan has the referral program, welcome emails and broadcasts, so the signup page, referral rewards and emails to your list are in one tool. LaunchList, KickoffLabs and GrowSurf tie their price to list size or monthly signups.
You can drive it from code, or hand it to an agent. API keys work on every plan, Free included, and there's an OpenAPI spec, an npm SDK and an MCP server.

When I'd pick something else:

A giveaway or contest: KickoffLabs.
A referral program inside a product that's already live: GrowSurf.
A managed beta at an established company with budget: Prefinery.

The table

Waitlister first because it's my post. The rest are alphabetical. Monthly prices, as each vendor's site listed them on October 10, 2026.

Tool	Paid plans from	Free option	Referrals	Public API
Waitlister (mine)	$19/mo	Free plan, 100 subscribers	From $19	Yes, every plan
GetWaitlist	$15/mo	7-day trial	From $15	Yes, from $15
GrowSurf	$179/mo ($125 billed yearly)	14-day trial (free plan is for affiliates only)	Core product	Yes
KickoffLabs	$19/mo	Free plan, 100 uniques/mo	Yes, plus giveaways	Yes
LaunchList	$9/mo for 500 contacts	Free plan, 100 contacts	Yes, Free included	Yes
Prefinery	$49/mo	14-day trial	Yes	Yes

Two things the table can't show.

What happens as the list grows. Past the free plan, Waitlister doesn't charge by subscriber count. Launch is $19 whether you have 200 people or 20,000. The limit that rises with the plan is email: 2,500 a month on Launch, 5,000 on Pro, 10,000 on Growth. So a big list you email often will push you up a plan. Three of the others scale with the list itself. LaunchList prices by contacts (at 5,000 contacts its plans are $19, $39 and $79). KickoffLabs' $19 plan takes 500 new leads a month. GrowSurf's entry plan covers 2,500 participants.

A free plan versus a trial. Three of these have a free plan you can keep: Waitlister, KickoffLabs and LaunchList. GrowSurf and Prefinery give you 14 days, and GetWaitlist gives you 7. GetWaitlist's free tier is only for accounts created before June 12, 2025, and GrowSurf's free plan is for affiliate programs, not referral programs. While you're still validating, a plan with no clock matters more than the headline price.

Why email to the list matters

A waitlist only works if you fill it and keep it warm until launch. The second half is the one people skip. Someone joins in March, hears nothing until a launch email in June, and by then doesn't remember signing up.

So before you pick a tool, check whether it emails your list itself, and on which plan. On Waitlister, welcome emails and broadcasts start at $19, and from $49 they can go out from your own domain. LaunchList and GetWaitlist also send broadcasts on their paid plans.

Waitlister in detail

What each plan adds. Yearly billing takes off two months.

Free, $0: 1 waitlist and 100 subscribers. The landing page builder, embeddable forms, surveys, CSV export, basic analytics and API access.
Launch, $19: unlimited subscribers and 3 waitlists. The referral program with points and a leaderboard, welcome emails and broadcasts (2,500 a month), double opt-in, CAPTCHA, a custom thank-you page, and no Waitlister branding.
Pro, $29: a custom domain, 5,000 emails a month, advanced analytics and conversion tracking.
Growth, $49: sending from your own email domain, one-click translation into 30+ languages, webhooks, integrations (Mailchimp, Klaviyo and others), the subscriber-data API and bulk import.
Business, $129: 5 team seats and 50,000 emails a month.

Some things that don't fit in a pricing row:

Hosted page or embed. Use the hosted landing page, or put the form on the site you already have. There are native embeds for Framer, Webflow, WordPress, Shopify, Squarespace and Bubble, among others.
Every signup gets a queue position and a share link, Free included. Launch adds the points and the leaderboard.
Referral fraud protection. Suspicious referrals don't earn credit, but the signup still goes through, so a real person isn't turned away.
An agent can do the whole setup. I've watched one create a waitlist, write and publish its landing page, verify a real signup and clean up after itself. Nobody opened the dashboard. Account API keys work on every plan for creating waitlists, adding signups, building and publishing landing pages, and reading stats. The quickest start is to point your agent at waitlister.me/skill.md. The OpenAPI spec is at waitlister.me/openapi.json, the SDK is waitlister on npm, and the MCP server is @waitlister/mcp in the official MCP registry. Add .md to any docs URL for raw markdown.

Where Waitlister isn't the answer

I'd rather you hear these from me than find them a week in.

On a small list, LaunchList is cheaper. Its free plan includes referral links, a leaderboard, and spam and fraud protection, and its paid plans start at $9 for 500 contacts. On Waitlister, points and the leaderboard need the $19 plan. The gap closes as the list grows: at 5,000 contacts, LaunchList's cheapest plan is also $19.
Your own domain is $29. Sending from your own email domain, webhooks and integrations are $49. If you need those on day one, the $19 plan won't cover them.
It's younger than Prefinery, which has been running since 2008. If your procurement team wants a long track record, Prefinery is the pick.
It's built for a launch. For a referral program that runs inside your app for years, GrowSurf is the right shape.

The others

GetWaitlist

A lightweight waitlist you embed in your own site. Each waitlist also gets a hosted page.

Pricing: $15 Basic, $50 Advanced, $250 Pro a month, less billed yearly. New accounts start with a 7-day trial.
Pick it if: you want referrals, a leaderboard, an API and webhooks on a $15 plan.
The catch: the free tier is only for accounts created before June 12, 2025. Sending from your own domain needs the $250 plan. Its own docs say the hosted page isn't meant to compete with full landing page builders.

GrowSurf

Referral and affiliate program software. It also publishes a template for a pre-launch referral waitlist.

Pricing: $179 a month, or $125 a month billed yearly, for up to 2,500 participants. 14-day trial for referral programs. The $0 plan is for affiliate programs and takes 3% of the revenue affiliates bring in.
Pick it if: you want a referral program inside a launched product. It also has the deepest developer tooling here: official API libraries in five languages (Waitlister has one SDK), an OpenAPI 3.1 spec and an MCP server.
The catch: it doesn't build your landing page. Its own pre-launch template has you build the page elsewhere and embed its referral widget. And $179 a month is several times the entry price of anything else in the table.

KickoffLabs

Giveaways first. Its homepage says "Launch a viral giveaway in minutes", and it runs waitlists and milestone rewards too.

Pricing: a free plan for 100 uniques a month, with branding. Then $19, $69, $145 and $289 a month, less billed yearly.
Pick it if: you're running a giveaway, where every entry and referral earns points toward a prize.
The catch: the $19 plan takes 500 new leads a month and still carries KickoffLabs branding. Waitlister's $19 plan has no subscriber cap and no branding.

LaunchList

The closest thing to Waitlister on this list. It relaunched as a subscription product (v2), and its old one-time plans are closed to new accounts. The new version also has a REST API with an OpenAPI 3.1 spec, signed webhooks and an MCP server.

Pricing: free up to 100 contacts. The paid plans (Collect, Launch, Grow) are priced by list size, from $9 a month for 500 contacts. LaunchList labels them beta prices.
Pick it if: your list will stay small and you want referrals for free or close to it. Its Launch plan also includes your own sending domain, from $19 on a small list.
The catch: the price rises with your list, and free-plan pages tell search engines not to index them.

Prefinery

Its site says it's been running since 2008.

Pricing: $49, $249 and $499 a month, or $39, $199 and $399 a month billed every six months. 14-day trial, no free plan.
Pick it if: you're an established company running a managed beta, and price isn't the constraint.
The catch: $49 a month is a steep start while you're still finding out whether anyone wants the product.

Also out there

ReferralHero: waitlists, contests, and affiliate and referral programs. $199 a month on its PRO plan, with a free plan for up to 25 subscribers.
EarlyParrot: referral campaigns aimed at SaaS, e-commerce, course creators and events, from $99 a month.
Viral Loops: referral campaigns. Its site blocks automated requests, so I couldn't check current prices. Its help center confirms a free trial.

How I'd choose

If you're still validating, start on a free plan, so a test that goes nowhere costs nothing.

If you're launching, decide the shape of the campaign before the tool. A queue with referrals and emails to the list, a giveaway, and a referral program inside a live app are different products. For the first one, I think Waitlister is the best tool you can use, and that's the job I built it for.

Everything above is checkable, and some of it will change. If you spot something that's already wrong, tell me in the comments and I'll fix it. If you want to check the Waitlister parts yourself, waitlister.me/pricing.md has every plan and limit in plain text, and the free plan needs no card.

I made my SaaS installable by AI agents. Here's what was broken.

Devin D — Fri, 14 Aug 2026 09:18:10 +0000

Two weeks ago I watched an agent run a full product launch on Waitlister, my waitlist tool.

It created the waitlist, generated and published a landing page, signed up a test address, checked the signup was real by fetching the public page unauthenticated, then unpublished and deleted everything it had made.

Nobody touched the dashboard.

The interesting part isn't that run. It's what I found while getting there, because almost none of it was visible from a browser.

Why I bothered

My users are pre-launch founders, which is exactly the group now building landing pages by prompting Claude, Cursor, or v0 instead of opening a site builder. "Add a waitlist to my site" is a normal thing to ask an agent to do, and increasingly nobody types my product name at all.

The uncomfortable part is when an agent hits a 404 or installs a package that doesn't exist, it doesn't debug. It picks a different tool in the next sentence and never tells the user it switched. You lose without ever seeing a bounce.

What I shipped, in order of how much it turned out to matter

Full API coverage for the whole job. Not most of it. More below, because this one was worth the other five combined.
A skill.md route. One page written for an agent rather than a person: a decision tree (no API key yet, go this way; account key, go that way), both code paths, and a self-check at the end so the agent can confirm it worked.
An OpenAPI spec at a fixed URL. Valid 3.0.3 at /openapi.json, all five endpoints, auth, rate limits, error shapes. Endpoint changes update the spec and the SDK types in the same PR or they don't merge.
A real npm SDK, plus four aliases under the names an agent is likely to reach for.
An MCP server, 14 tools, so agents that speak MCP get typed calls instead of reading my docs.
llms.txt and llms-full.txt, an index of the docs in plain text with a short block at the top saying what this product is and where the golden path starts.

What was broken

Honest list.

The file I wrote for agents was the one file agents couldn't read. My llms.txt is proxied from a vendor, the proxy forwards the caller's user-agent, and the vendor had AI-bot blocking switched on by default. Every AI crawler got a 403 on the document whose only purpose is being read by AI
crawlers. I found it by requesting my own files with eight bot user-agents and diffing the status codes. One vendor toggle can put it back, silently, which is why the check now runs on a schedule.

llms-full.txt is too big to be read at answer time. It's 961 KB and grows with every docs page. It serves from my side in about 1.3 seconds, and Claude's answer-time fetcher still timed out on it at 60 seconds. The small index is the one that actually gets read. I haven't fixed this yet;
the options are trimming it or splitting it, and I've done neither.

Agents guess your package name. waitlister-js, waitlister-sdk, waitlister-node, @waitlister/sdk. Instead of arguing with that, I published all four as real packages that re-export the SDK and carry a deprecation notice pointing at the canonical name. A wrong guess installs and self-corrects.

My email validator rejected valid addresses. Agents test with plus-tags, because that's how you make a disposable address on an account you already own. My validator refused some of them. Human users with Gmail aliases had been hitting the same wall for as long as the rule existed.

My 404s weren't 404s. Unknown doc slugs returned a soft page with a 200. An agent reading status codes concludes the page exists and that it guessed the URL right, then builds on it. Real 404s, plus a 301 from the old getting-started URL.

The single page that would have saved five fetches was labeled for the wrong reader. In the first live test the agent's own friction report said the docs were split across pages with no single page giving the complete picture, so it fetched five. skill.md is that page, and /docs/api linked to it in a callout at the very top. The callout was headed "Integrating with an AI agent," which is a label about who it's for, and the agent was reading through a fetch-summarizer where that reads as a sidebar. Reframed as "Fastest path: complete single-page integration guide," it started landing. The link was never missing. It was filed under the wrong thing.

Every run used to die at the same sentence. The agent could create a waitlist through the API and then had to say "now open the dashboard to build your landing page." That one gap ended the automated path every time, no matter how good the rest of the surface was. Creating, updating, and publishing a landing page over the API is what made an end-to-end run possible at all.

The one thing I'd tell someone starting this

Test with the real fetchers, not with curl. Every failure above lived in the gap between what my server sends and what an agent's toolchain actually receives: a user-agent rewritten in transit, a file that serves fine but times out at answer time, a status code that lies, a link that survives the fetch but not the summary. Curl told me everything was fine. It was, for curl.

Where I've got to: four consecutive live runs with zero wrong guesses, a complete correct integration plan from public surfaces alone in about 90 seconds, and a waitlist created from an empty account in three minutes and eighteen seconds.

Check it yourself

All of it is live. If you want to see what an agent actually receives, point yours at waitlister.me/skill.md and ask it to set up a waitlist.

The same path written for a person is at waitlister.me/growth-hub/guides/set-up-waitlist-with-ai-agent.