DEV Community: LaunchSignal

I checked 11 launch platforms for an llms.txt. Four answered, one sent a challenge page

LaunchSignal — Thu, 29 Oct 2026 11:55:11 +0000

On October 19 I ran a small, boring test: fetch /llms.txt from the root of 11 launch platforms and directories and see who answers. Ten days later, on October 29, 2026, I ran it again before writing this up. The picture had already moved.

llms.txt is a proposal for a plain markdown file at a site's root that tells a language model what the site is and where the useful pages are. Nobody is required to publish one, and Google's own guidance says you don't need new AI text files to appear in its AI features. So a missing file isn't a failing. I just wanted to know what an agent finds if it goes looking, because more of my own work now starts with an agent fetching a URL.

How I checked

One curl per domain, following redirects, with an ordinary desktop Chrome user agent:

curl -sL -A "Mozilla/5.0 ... Chrome/130.0.0.0 Safari/537.36" \
  -o /dev/null -w '%{http_code} %{content_type} %{url_effective}' \
  https://<domain>/llms.txt

I also tried /llms-full.txt, the longer companion file some sites publish. I counted a site as answering only when it returned a 200 with text/plain. A 404 counts as "no file". A 403 challenge page counts as "blocked the fetch", not "missing", because those are different things.

What came back

Platform	/llms.txt	What the file says
DevHunt	200, text/plain, 6 KB	What DevHunt is, free listing vs. paid launch options, key pages, URL patterns for tool, alternatives and compare pages, categories. No submission API listed.
TinyLaunch	200, text/plain, 42 KB	An "Agent Guide": a full submit flow over its REST API, email OTP auth, maker profile, startup, launch scheduling, categories, limits, error codes.
BetaList	200, text/plain, 3 KB	What gets featured, links to an Agent API for drafting a submission without an account, which a human founder then claims; submission criteria and help pages.
Uneed	200, text/plain, 792 KB	What Uneed is, a read-only MCP server and REST API for product data, a link to an agent launch guide (email OTP), then long lists of products, reviews and alternatives.
Product Hunt	403 to curl (Cloudflare challenge)	Not readable with plain curl today. A different fetcher did get it: site overview, URL patterns, leaderboards, categories, and an attribution line.
Hacker News	404	No file
Fazier	404	No file
Open Launch	404	No file
SaaSHub	404	No file
Peerlist	404	No file
Microlaunch	404	No file

On /llms-full.txt: Uneed serves one (about 9 MB of text). TinyLaunch's path redirected to a login page, which returns 200 but is HTML, so I don't count it. Everyone else returned a 404 or the same challenge page.

What changed in ten days

Three results flipped since October 19:

BetaList returned a 404 on the 19th. Today it serves a short, well-organized file.
Uneed blocked my fetch on the 19th with a challenge page. Today it answered with the largest file in the set.
Product Hunt answered on the 19th. Today plain curl got a Cloudflare "Just a moment..." page with cf-mitigated: challenge, on both the apex and www. The file is still there; the same URL fetched through a different tool came back fine, with links dated today. I don't know why my request was challenged this time, only what came back.

That last one is the practical lesson. Whether an agent "can read" a site isn't a property of the site alone. It depends on who is asking, from where, and on which day. A single check is a snapshot.

Three kinds of file

Reading the four files that answered, they're doing different jobs.

The map. DevHunt's file, and Product Hunt's when it's reachable, explain what the site is and how its URLs are shaped: /tool/{slug}, /compare/{a}-vs-{b}, /products/{slug}/alternatives, daily and weekly leaderboard paths. That's what an assistant needs to answer "what are alternatives to X" by going straight to the right page instead of guessing. Product Hunt's also asks for something back: list a product's name and tagline first, and attribute the data to Product Hunt.

The runbook. TinyLaunch's file opens with "You are launching a startup on TinyLaunch on behalf of a user, end-to-end, without a browser." It then lists the eight endpoints the flow needs, which ones need a bearer token, and how to handle the email code. It even tells the agent to use its host's structured-question tool rather than printing options as text. That's written for a coding agent mid-task, not for a crawler.

The handoff. BetaList's file points to an Agent API where an agent drafts the submission and a human founder claims it. Uneed's does both a read side, an MCP server and REST API for its product data, and a write side, a separate launch guide for agents. I checked that the linked pages exist (betalist.com/agent and uneed.best/launch.txt both returned 200). I did not run either flow.

What none of the files did was hide the human step. Every write path I saw still routes through a person: an emailed code, or a founder claiming the draft. I think that's the right shape.

What the 404s mean

Not much on their own. Hacker News is a discussion site with an official read API documented on GitHub. The others have perfectly readable HTML pages, and a search crawler doesn't need a root markdown file to index them. The 404 only matters in one narrow case: an agent that checks /llms.txt first will learn nothing about how submissions work there and will fall back to reading the HTML or asking you.

What I'm taking from it

If you run a site that takes submissions, the most useful thing an llms.txt can carry is the submission path, plainly written, including the step that needs a human.
Write it for the agent that will act on it, not just the crawler that indexes it. TinyLaunch's step list and error codes are a good model of that.
Re-check anything you cite. Three of eleven results changed in ten days, and one of them seems to depend on how it was fetched.
Keep the raw responses. I saved every body and header from today's run, which is how I could tell a missing file from a challenge page.

The file I keep for LaunchSignal at launchsignal.ai/llms.txt is held to the same test: it names the JSON API and MCP submit paths, the error codes, and the fact that a submission stays pending until a person reviews it.

Two products, one name: telling AI assistants which one you mean

LaunchSignal — Thu, 22 Oct 2026 15:08:25 +0000

Tonight I typed my product's name into a web search, the way a stranger would. Five results came back:

launchsignal.io, an idea-validation tool: landing pages, questionnaires, and checkout tests to measure intent before you build.
A blog post from launchsignal.io.
launchsignal.ai, which is mine.
launchsignal.app, a tool for finding beta testers for your app before launch.
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 sent one product to a pile of launch sites. Seven weeks later, here's what's live

LaunchSignal — Tue, 20 Oct 2026 02:07:55 +0000

At the end of August I spent most of a week submitting one product to launch sites and directories. Free tiers only, same copy everywhere, one contact address, one logo. I kept a log because I wanted to know what actually comes out the other end.

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.

When an agent submits, the error response is the interface

LaunchSignal — Sun, 18 Oct 2026 08:15:04 +0000

When a person submits a form, the interface is the form. When an agent submits, the interface is whatever comes back.

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?

My product's second audience doesn't have eyes

LaunchSignal — Sat, 10 Oct 2026 15:17:17 +0000

I've been reading my own landing page wrong.

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?

Launch day is the worst day to judge a product

LaunchSignal — Sat, 10 Oct 2026 08:04:36 +0000

Most launches I've watched, my own included, have the same shape. Day one is a screenshot, a one-liner and a link. And the product on that day is the least it will ever be: half the settings are stubs, onboarding is a paragraph, and something on the page says "soon."

Then week three happens. The bug someone reported in the comments got fixed. The empty state finally has a real example in it. The thing the maker kept apologizing for on launch day is just gone. Honestly, that's usually the first version I'd recommend to a friend.

By week three, though, nobody's looking. The launch post has scrolled away, and the listing still shows the day-one screenshot and the day-one description. If someone finds it a month later, they're judging the worst version of the thing.

A few habits I've picked up on side projects because of this:

Write the listing like a changelog entry, not a billboard. "Does X. Doesn't do Y yet." That sentence ages a lot better than "the all-in-one platform for…"
Date the screenshot, at least in your head. If the image is from launch week, it's probably lying by now.
Go back on day 21 and read the listing as a stranger would. Fix the one sentence that's no longer true.
Treat "here's what changed since launch" as a second launch. It's often more interesting than the first post, because now there's something real to show.

None of this is clever. It's just admitting that a launch is a timestamp, not a verdict.

I'm working on LaunchSignal, a place to publish new products, and this is the part I keep turning over: a listing gets written on day one but read for months. How do you keep yours honest once the launch-day traffic is gone?

You hit submit. Then… nothing.

LaunchSignal — Thu, 01 Oct 2026 08:15:16 +0000

There’s a beat nobody puts in the launch checklist.

You finish the weekend MVP. You find a place that will take a listing without a calendar slot. You paste the URL, write two sentences, hit submit.

Then the tab goes quiet.

No upvotes. No “congrats!” thread. Just a pending state and your own brain looping: is the description dumb? Did the link 404 for them? Did I just throw a working product into a void?

I’ve started treating that silence as normal, not a verdict.

Review queues are slow on purpose — someone has to check that the site loads and isn’t spam. Browsers don’t show up in the first hour. Most “launches” that feel loud are loud because a person scheduled the noise, not because the product magically found an audience the second it existed.

What helps me while I wait:

Open the listing the way a stranger would. If the one-liner still only makes sense to me, rewrite it once.
Don’t refresh the moderation status like it’s a stock ticker.
Ship a tiny fix on the product itself instead of rewriting the same pitch five times.

If you’re in that quiet hour right now: the empty inbox isn’t proof it was a bad hang. It’s usually just the gap between “submitted” and “someone else scrolls past it on a Tuesday.”

I’ve been hanging new builds on LaunchSignal for that same reason — free submit, human review, then it sits where people browse fresh launches. Curious how long you usually wait before you assume a listing is dead.

The hardest part of listing a new product isn’t the form

LaunchSignal — Thu, 24 Sep 2026 05:41:30 +0000

I’ve been hanging around launch boards again — Product Hunt calendars, directory queues, little “submit your tool” pages.

The form is usually easy. Name, URL, a short description. Done.

What stalls people (me included) is the one or two sentences that have to carry the product for a stranger who will never open the README. After a Cursor weekend, the build is fresh in your head. You know the edge cases. The browser doesn’t. They only see: does this do something I recognize in under five seconds?

A few patterns that keep showing up when a listing feels thin:

It’s still talking to the builder (“AI-powered platform for…”) instead of the next person (“paste a URL, get X back”).
The category is “AI” and nothing else, so it disappears into a pile of lookalikes.
The link works, but there’s no clear “what happens if I click.”

None of this is marketing theater. It’s just making the hang-place useful for people who browse, not only for people who ship.

I’ve been poking at that gap on LaunchSignal — free submit, human review, then it shows up for folks looking for fresh launches. If you’re staring at a blank description box tonight, write the sentence you’d say to a friend who asks “wait, what does it do?” first. The form can wait thirty seconds.

Curious what one-liner you’ve actually kept after a rewrite.

After the agent ships the MVP, where should it hang the product?

LaunchSignal — Fri, 18 Sep 2026 09:26:55 +0000

I keep hitting the same awkward beat with Cursor / Claude Code: agents ship MVPs fast, then stall on where to hang the product. Submit should be callable (JSON/MCP), not a second human form.

LaunchSignal gives agents a place to ship:

https://launchsignal.ai
API: https://launchsignal.ai/docs/api
MCP: https://launchsignal.ai/mcp
llms.txt: https://launchsignal.ai/llms.txt

Longer notes:

Your coding agent can submit a product without a second form

LaunchSignal — Tue, 15 Sep 2026 10:13:29 +0000

In the last post I wrote about the awkward beat after Cursor ships an MVP: the agent builds fine, then doesn’t know where to hang the thing.

We already had REST + OpenAPI for that. Now there’s also a public MCP endpoint, same three moves as the API:

submit_product
list_products
get_product

Point Cursor/Claude at https://launchsignal.ai/mcp (Streamable HTTP, no OAuth this round). Example mcp.json:

{
  "mcpServers": {
    "launchsignal": {
      "url": "https://launchsignal.ai/mcp"
    }
  }
}

Docs/OpenAPI still at https://launchsignal.ai/docs/api and https://launchsignal.ai/openapi.json. Prefer list/get for reads; submit creates a pending row a human reviews — don’t spam it.

If you already teach agents to “ship,” curious whether MCP or a short natural-language submit prompt sticks better.

After Cursor ships the MVP: what should the agent do next?

LaunchSignal — Tue, 15 Sep 2026 10:09:55 +0000

I keep hitting the same awkward beat.

Cursor or Claude Code can get a thin MVP onto a real URL in a weekend. The agent is great at the build loop. Then you ask it — half-joking — “okay, where do we hang this?” and it stalls. Product Hunt wants a calendar. Half the directories want a human circus. Your own domain looks empty.

Shipping got faster than publishing. For people wiring agents, that’s a concrete gap: submit should be a step the assistant can call, not a second form you fill by hand.

We’ve been poking at that on LaunchSignal. Humans can still use the HTML form. For agents, the JSON API is the primary path now:

Docs: https://launchsignal.ai/docs/api
OpenAPI: https://launchsignal.ai/openapi.json
Site map for models: https://launchsignal.ai/llms.txt

Minimal submit (pending review):

curl -sS -X POST https://launchsignal.ai/api/v1/products \
  -H 'content-type: application/json' \
  -H 'accept: application/json' \
  -d '{
    "name": "Acme",
    "url": "https://example.com",
    "description": "Does one useful thing.",
    "category": "AI",
    "email": "you@example.com"
  }'

Required: name, url, description, category, email. Optional: logo_url. List/detail: GET /api/v1/products, GET /api/v1/products/:slug.

MCP isn’t shipped yet — REST + OpenAPI is the bridge for now. If your agent already reads docs or OpenAPI, pointing it at those two URLs is enough to try.

Curious whether you’d rather hand the agent a JSON schema or just a short natural-language “submit this product” prompt.

I shipped an AI weekend MVP and then… nowhere to hang it

LaunchSignal — Tue, 15 Sep 2026 09:39:48 +0000

I keep seeing the same loop.

Someone (me included) spends a Saturday with Cursor or Claude and actually finishes something: a thin MVP, a weird little tool, a demo that works on a real URL. The build part got weirdly easy.

The awkward part starts after you push.

Product Hunt wants a launch day. Most directories want money, a queue, or a small circus of upvotes. Your own domain looks lonely. Friends say “cool” and move on. You’re left with a working product and no natural place to put it where strangers might stumble across it.

I don’t think this is a motivation problem. It’s a logistics gap. Shipping got faster than publishing.

I’ve been poking at that gap — a simple public board where you can hang a new product without waiting for a calendar slot. If you’re in the same spot: https://launchsignal.ai/?utm_source=devto&utm_medium=post&utm_campaign=maker-note

Curious how other people handle the “done building, now what” week.