1. launchsignal.io, an idea-validation tool: landing pages, questionnaires, and checkout tests to measure intent before you build.
2. A blog post from launchsignal.io.
3. launchsignal.ai, which is mine.
4. launchsignal.app, a tool for finding beta testers for your app before launch.
5. Another page of mine.

At least three products called LaunchSignal, three domains, three completely different jobs. The search tool also wrote a short AI summary above the results, and that summary described LaunchSignal entirely as the idea-validation product. Not wrong, exactly. Just not us.

That's the problem in one screenshot. When someone asks an assistant about "LaunchSignal", the answer gets built from whatever pages it finds, and right now those pages mostly describe someone else.

None of us did anything wrong

Short, descriptive names collide. Launch and signal are about as generic as product words get. The .io product is a real tool for validating ideas. The .app one is a real tool for recruiting testers. A third-party comparison site, idea-launch.io, has published pages comparing itself with "LaunchSignal" that are clearly about the .io product. That's a fair thing to write about a product with that name.

Nobody owns the word, and asking anyone to rename isn't on the table. The only part I control is how clearly my own pages say which one they are.

What we actually changed

1. One plain sentence, in two places. The homepage now carries this line as visible text, not hidden metadata:

LaunchSignal (launchsignal.ai) is a product publishing and distribution site. It is not affiliated with launchsignal.io or other tools of the same name.

The same sentence sits near the top of our llms.txt as a note for crawlers. llms.txt is a proposal for a short markdown file at the site root that summarizes the site for agents at the moment they need it. That's exactly when an agent would be trying to work out which LaunchSignal it's looking at.

I kept it boring on purpose. Domain in brackets, what the site is in a few words, what it isn't. No adjectives, nothing about the other products beyond their domain. If an assistant ever repeats it word for word, I want it to be a line I'm happy to see repeated.

2. Structured data that links our own accounts. The homepage and the About page have a schema.org Organization block in JSON-LD with a sameAs list pointing to our Dev.to, Hashnode and Medium accounts. Google's organization structured data docs describe sameAs as a page on another site with more information about your organization, such as a profile page. The idea is simple: give machines a small, consistent cluster of pages that are all clearly the same entity, so the posts I write elsewhere connect back to the right domain rather than floating free.

3. An About page that says what we are. Positioning, vision and principles in plain text, linked from llms.txt. If an assistant is trying to work out what the .ai one is for, that's the page that should answer it.

What we haven't fixed: our own old listings

This part is on us. Back in August the product was something else, a public radar of new launches from Product Hunt, Hacker News and GitHub. In September it changed direction. But the listings we created back then didn't change with it.

Re-checked tonight, these still describe the radar:

• Fazier
• Open Launch (scheduled, not launched yet)
• SaaSHub (still pending)
• dotstore. I didn't submit this one; the page says it was listed by dotstore's editors, and it picked up the radar description from somewhere.

So the collision isn't only between three different products. It's also between the current version of mine and a version that no longer exists. To an assistant reading the web, "LaunchSignal (.ai) is a launch radar" and "LaunchSignal (.ai) is a publishing site" are two conflicting claims about the same domain. I can't fully blame the machines if they hedge.

Some of these I can edit; at least one field on Open Launch is locked after submission.

What I don't know yet

I don't know whether any of this works. I didn't save a "before" snapshot of assistant answers, so I can't show you a before and after, and I'm not going to pretend otherwise. Google's own guidance says you don't need new machine-readable files, AI text files or markup to appear in its AI features. So llms.txt and sameAs aren't switches; they're cheap, honest signals for whichever systems do read them.

What I'm confident about is narrower: every page I control now says the same thing, in the same words, with the domain attached. That's the part of disambiguation that's actually in a maker's hands.

If your name collides too

• Search your own name in a private window and write down exactly what comes back, including any AI summary. That's your baseline.
• Add one visible, factual sentence to your homepage: your domain, what you are, what you're not.
• Put the same sentence in llms.txt if you have one.
• Add sameAs links in your Organization markup, only to accounts you actually run.
• Audit old directory listings. They outlive pivots, and they're often the pages with the most outdated description of you.
• Be generous about the others. Describe them by domain and leave it there.

I wrote more about the different ways assistants find products, from search crawlers to llms.txt to APIs, in How AI assistants find and recommend new products, on the site of the LaunchSignal that's a free product publishing and listing site built for AI agents.

I re-checked everything this morning, a little over seven weeks later. Here's the honest state of it.

What's live

Indie Hackers product page. Live the same day, and it's still the only listing I can point to without a caveat. A product post I published there sits right on the page, so readers see what the thing is and why it exists in one place. That part works well.

That's the whole "live" list.

What's scheduled

Open Launch. I went with the free launch, and I got a date straight away: February 23, 2027, 08:00 UTC. Their pricing page says free launches can be scheduled up to 180 days out, so that's exactly what I signed up for. I like that I got a real slot in the same daily lineup and a date I can put in a calendar, not "we'll see".

One thing I learned the hard way: after submitting, the tech-stack tag couldn't be edited. It says Next.js, and the product isn't built on Next.js. We added a line to the description instead, since that field stayed editable.

What's still in a queue

SaaSHub. Submitted September 2. This morning the page still says "Pending approval". The estimate I saw at the time was roughly a month, so it's running long, but their submit page is upfront that every product goes through approval. It also tells you exactly how to move up the queue: list your competitors, and verify with an email on your own domain. The listing already exists as a page, sitting next to the alternatives people compare it with. One thing to know: the tracking parameters on my URL were stripped.

Launching Next. It accepted the free listing on August 28 and told me upfront I was in a queue of about four months. I couldn't find a public page this morning, which matches that wait. I appreciated being told the wait in advance.

FutureTools. The form took the submission with no account needed, and said it would be reviewed. As of this morning there's no public page at the URL I'd expect.

ToolScout and Launch Llama. Both were "in review" the last time I looked, and I haven't found a public page for either.

TinyLaunch. Submitted September 2 to the free queue, "Waiting for approval", with a planned launch date of October 5 if approved. I couldn't confirm what happened after that. The product pages sit behind a login, and nothing I could see publicly settles it. I'm leaving it as unconfirmed rather than guessing.

Where I stopped

• FoundrList. The free launch queue needs either a verified badge on your site or 3 upvotes and 1 community comment. I'd uploaded the logo and the draft page existed, but I didn't want to go around asking for upvotes, so I stopped there. To their credit, the rule is spelled out before you commit.
• Fazier. The free tier asks for a link back from your homepage. We added one to the footer, then hit a community-comment step before we could submit and parked it. The free option is clearly laid out; I just didn't finish it.
• Peerlist. You need a verified profile before you can launch, and verification was waiting on an emailed code. It's a sensible spam filter. We haven't finished it yet.
• WIP. Turned out to need a paid membership. Skipped.
• AlternativeTo. Sign-up hit a CAPTCHA that needed a human, and it's still unresolved.
• Oranyx. The form returned "Something went wrong" twice. I dropped it rather than keep hammering it.
• OpenFuture AI and AItrendytools. Sign-in was Google or Discord only (Google only for AItrendytools), and I didn't have the right session ready.
• IndexOf.AI needed sign-in; BroUseAI sat behind a Cloudflare Turnstile check. Both are paused.

What I'd tell myself in August

Most results are queues, not launches. After seven weeks I have one live page, one date in February, and a handful of "pending". None of that is anyone misbehaving. Free tiers are free because they're queued. Plan for months, not days, and don't judge a channel by week one.

Every one I used in August was a form. None offered an API call I could use back then (TinyLaunch has since documented an agent submission flow). A lot of the friction (CAPTCHAs, Google-only sign-in, emailed codes, comment gates) exists to stop spam bots, and it's reasonable for that. It also means an agent working for you hits the same walls a bot does, so a human ends up doing the last step every time.

Listings freeze your positioning. In mid-September the product changed direction. Every listing I just re-checked, live or pending, still describes the old version, because that's what I typed in August. When those queues finally clear, the old description is what goes live, and it's what search crawlers and AI assistants will read and quote. If I did it again, I'd write the description for the product as it will be when the listing appears, and keep a list of every place I have to update.

Keep a log with a URL per site. Status, date, the public URL (or "none yet"), and whether your tracking survived. Without it I'd have no idea where half of these stand, and I'd probably have submitted twice to the ones that were still quietly pending.

Read the free tier's fine print first. Backlink requirements, vote thresholds, queue lengths and paid-only "free" options were all written down somewhere. Every surprise I had was something I could have read beforehand.

These days I'm building LaunchSignal, a listing site that takes submissions through a form, a JSON API or an MCP tool. I also wrote up how the launch platforms compare on price, review and API access, using only their own pages: Product Hunt alternatives for indie and AI makers.

I didn't think much about this until I sat down to document a small listing API properly. The success path barely needs explaining. An agent that gets a 201 is done. Everything else is where it has to decide what to do next, usually with no human watching.

So I started reading each response as an instruction the agent has to act on.

400 with fields: "fix this, then retry once." A validation error like invalid_category comes back with fields.category listing the allowed values. The agent doesn't have to guess. It reads the list, corrects the payload, and sends it again. A red outline on a form field does nothing for a model.

409 duplicate_domain: "stop, it's already there." It fires whether the existing listing is approved or still pending. For an agent, this is close to a success: the job is already done, or already in the queue. The wrong move is to tweak the URL and try again.

400 rejected_policy: "don't retry, tell your human." There's nothing to fix in the payload. The only honest next step is to report back. I'd rather say that plainly than return something vague and let the agent loop.

429 rate_limited: "not now." On mine it's scoped to pending submissions per email over 24 hours, so retrying right away changes nothing. A distinct code lets the agent stop and hand off instead of hammering.

201 with status: "pending": "received, not live." This is the one I'd underline. The response carries an id, a slug, and next_steps, but a person still reviews the listing. A careful agent then checks its work: it calls get_product (or GET /api/v1/products/:slug) and gets not_found. Read naively, that looks like the submit failed. It didn't. The read endpoints only return approved listings, which is why the 404 message says "not found or not approved." The agent should keep the slug and status from the 201 and read that 404 as "not visible yet," not "missing." The real confirmation comes later, when get_product or list_products returns the listing.

The gap between "accepted" and "visible" is where I'd expect most agent confusion on any site that moderates. If the states aren't spelled out, the agent fills the silence with a retry, and now you have duplicates.

I wrote up the whole flow, with each code and what to do about it, in this guide.

What I'm keeping:

• Every error gets a stable code, not just a message. Messages are for people. Codes are for branching.
• "Fix and retry," "stop," and "wait" should look different. An agent can only behave well if they do.
• Say what's pending. A review queue that's invisible from the API looks like a broken API.
• Make reads the confirmation step, and document what they won't show.

A pretty form reassures the person who already decided to submit. An honest error tells a machine what actually happened, and that's what it needs so it doesn't make a mess on someone's behalf.

The API I've been describing is LaunchSignal's. Do your agents branch on error codes, or just retry until something sticks?

For years I tuned pages for a person scrolling on a phone: hero line, screenshot, a button. Lately I've started reading them the way an agent does: fetch the URL, strip the CSS, and see what's left. Usually what's left is a nav menu, cookie banner text, and a tagline that only makes sense next to an image that's gone now.

That changed how I think about discovery. More and more often, the first thing that "sees" a new product is a model looking something up for someone, not a person. It doesn't look at your hero image. It reads text and calls endpoints.

Here are three layers I now check on any site I build, from cheapest to most work.

1. llms.txt: a page that tells a machine what it's looking at. It's just markdown at the root. What the thing is, which pages matter, and what it isn't. That last part surprised me. One line like "this is unrelated to " does more for disambiguation than any meta tag I've written. It's a cheap file, and it forces you to describe your product without adjectives.

2. A small JSON API with boring, predictable errors. An agent can't squint at a red outline on a form field. It needs { "ok": false, "error": "invalid_category" } and a list of allowed values somewhere it can read. An OpenAPI file, even a minimal one, turns "figure out this site" into "read the contract." The error codes ended up mattering more to me than the success response.

3. MCP, for when the agent is already inside an editor or chat. An MCP server is the same contract, but the tool shows up as something the model can call directly. It's one URL in a config file. Reads such as list and get are the natural starting point. Writes need more care.

What I keep relearning is that discovery by machines is mostly about legibility, not ranking. No algorithm is there to game. Either the model can parse what you are and what you accept, or it can't and moves on to something it can.

A few habits that came out of this:

• I write the one-line description first and paste it everywhere unchanged. Agents compare sources, and inconsistent descriptions read as noise.
• Categories are a closed list, not free text. Machines can deal with enums but struggle with vibes.
• Anything a machine writes gets a human review. "Authless and public" means you should expect enthusiastic callers, so writes land in a pending state, not live.
• I curl my own pages with no JavaScript about once a month. It's humbling.

None of this replaces people finding your work. But the person increasingly arrives through something that read your site first, so it's worth making sure that thing came away with the right idea.

I've been trying all three layers on a small listing site, LaunchSignal, where submissions come in through a JSON API and an MCP server as well as the form. I'm still learning which parts agents actually use.

Curious what others do here: do you treat machine readers as a real audience yet, or still as an afterthought?