The List Is the Easy Part: 393 SaaS Directories and the Agent That Has to Use Them

What he actually sells

The pitch is simple. You clone the repo, point your agent at it, and the agent works through a playbook for each platform inside your signed-in Chrome. You write a product brief once. A local tracker on 127.0.0.1:8765 shows what is live, pending, or blocked. You step in for CAPTCHAs, two-factor codes, and logins.

The numbers on the page are more candid than most landing pages. Of the 299 guides, 86 are verified free, 157 are "conditional free", 4 are research-only, and 52 are currently unavailable. Free listings sit in review queues for anywhere from a day to about twelve weeks, and each directory takes roughly three to five minutes of agent time. He reports two of his own domains rising from DR 0 to 26 and from 9 to 25 in under two weeks, measured with FrogDR. He also says plainly that he has not measured traffic or customers.

Read that breakdown again. In a product with 299 guides, only 86 are plainly free. The word "free" is a claim until someone checks it. Our table has the same weakness today. The Fee column says Free or Paid, our paid page says these directories "typically" charge, and no row carries a date for when we last looked. That is the first thing to fix.

What 393 rows are, and what they are not

Our table has 393 directories: 253 free and 140 paid. Sort by Domain Rating and the top reads like a mixed bag. Google Business Profile sits at 100, Trustpilot at 97, and TechCrunch at 96 on the paid side. Further down you find review sites, AI tool lists, design galleries, publications that charge for a feature, Hacker News, and a long run of subreddits.

That mix matters, because "SaaS directory" covers very different animals. A review site wants proof you are a real company. A design gallery wants a screenshot-worthy page. A subreddit wants a post that does not read like an ad. One playbook cannot cover them all, which is why LaunchRepo ships one per platform.

Then there is the DR column. Domain Rating is a score from Ahrefs, and Google has said it does not use third-party authority metrics like it as a ranking factor. Use it to compare directories against each other, not as a promise about what a listing will do for you.

Do the links even count? One independent check of 41 directories found 11 that gave a followed link, 6 that were nofollow, and 6 with no crawlable link, while 18 had not been checked yet. The same page notes that Google's spam policies name low-quality directory links as link spam. A separate 2026 analysis goes further and argues that directories with no review queue at all are the ones most likely to be spam networks, and that a profile made only of directory links looks odd in its own right.

So the working rule is: fewer directories, picked for fit, with a human or a review queue behind them. We covered the free end of this in How to Get Free Traffic to Your Website in 2026, and the free and paid pages split the table if you want to start with the free side.

The first idea was WebMCP

If an agent has to submit to 393 sites, the cleanest version would be sites that tell the agent what they can do. That is the promise of WebMCP, which we explained through a sweet shop in WebMCP, Explained Through a Sweet Shop.

It does not help here, for a plain reason: the website has to opt in. Each site must add code that registers its forms and actions as tools. One May 2026 audit found that none of the mainstream AI agents were calling those tools on live websites yet. Chrome's own WebMCP docs say agents cannot call the tools headlessly, and the spec is still a draft whose API surface has been moving. Three hundred small directories will not adopt it before you want your launch done.

WebMCP could make sense later on our side, so an agent could read the table and mark rows. For submissions, the agent has to read each site the way a person does.

So the agent reads pages like a person

That points to browser automation. The main options are Playwright scripts, Playwright MCP, Chrome DevTools MCP, and AI layers like Stagehand or browser-use. Playwright MCP gives the agent an accessibility snapshot of the page instead of screenshots, which keeps steps cheap on well-built pages and hurts on messy ones. One analysis suggests a hybrid: plain Playwright for the roughly 80 percent of steps that never change, and an AI tool for the rest. It also claims the MCP route costs far more tokens per task than the CLI. That is one source, so measure it on your own runs before you believe it.

LaunchRepo takes the real-Chrome route, with the agent attached to a browser you are already signed in to. We will do the same for anything with a login, and reach for scripts where a directory never changes its form.

The bigger design decision was not the browser, though.

Do the AI part once

The expensive thing about an agent is making it discover everything again every time. "Find the submit page, work out what it wants, decide whether it is worth it" is the slow, token-hungry bit. It does not need to happen on every run.

So we split the work in two:

1. Discovery, once per directory. A script opens the site and collects the links that look like submit, add, list, or launch. An LLM reads the page and writes a playbook. It stays marked draft until a real test submission works, and only then becomes verified.
2. Execution, per product. The agent picks up the next task, follows the playbook, and reports back.

A playbook can be a small file:

# AlternativeTo
Fee: free · Checked: 2026-10-04 · Needs: account, logo, 3 screenshots
Backlink or badge required: no
Steps: sign in, Add application, fill fields, pick category
Human needed: email confirmation, CAPTCHA
Done when: listing URL appears under "My apps"
Traps: duplicates are rejected if the name matches an existing entry

The Checked date is the part that matters most. Forms change, free tiers turn into paid ones, and a playbook that is six months old is a guess.

Four gates every directory puts in front of you

Before a directory asks for your URL, it quietly asks four questions. Each one needs its own answer.

• Do I need an account? Some want none, some want email and password, some want Google, GitHub, or X. For email signups, give the agent a dedicated inbox with plus-addresses so it can click confirmation links. For social logins, run it in a Chrome profile you signed in to once, and keep passwords out of prompts and playbooks.
• Do I need a badge or backlink from you? Some directories want a link back before they approve you. Keep the badge snippet in the product brief, and run a preflight check that fetches your site and looks for it. If the badge is missing, the task waits as blocked until you deploy it.
• Do I want money? The default is to stop before any paid step. A paid listing buys speed or placement, not a guaranteed followed link, so it should be a decision you make, row by row.
• Do I need a human? CAPTCHAs and two-factor codes pause the run with a needs_human flag. We do not try to get around them.

Some directories also forbid automated sign-ups in their terms, so each row gets an automation_ok flag.

Submitted is not live

The most useful column in a tracker is the one that separates "I sent it" from "it exists".

A free listing can sit in a queue for weeks. So each submission moves through states: queued, working, needs_human, submitted, pending_review, live, rejected, failed. A scheduled check revisits pending ones, looks for the listing URL, and confirms the backlink is present. Only then does the row turn live and the link fill in.

That one column is also how you learn which directories are worth the effort. After twenty runs you know which ones approved you, which ones sent traffic, and which ones sat there.

A table for people who log in

Our directories page already says you need to log in to download the CSV. The next step is small: for logged-in users, add a few columns to the same table at the same URL. Status, listing link, notes, last checked. It is closer to a simple Notion table than to a full CRM, and we are keeping it that way on purpose, because the point is to see at a glance what is done and what is waiting.

Not built yet. I am telling you now because that is the order in which we want to do it: table first, repo second.

What goes in the repo

The plan is an open-source repo you run locally:

launch-kit/
  brief/product.md        # your facts, approved claims, logos, screenshots
  directories.json        # name, url, fee, auth, backlink rule, checked date
  playbooks/              # one file per directory
  tracker/                # Hono API plus a small dashboard
  prompts/run-10.md       # "submit to the next 10 suitable, pause on CAPTCHA"

The tracker follows the same pattern as Tubelog: a Hono backend, a small Vite front end, local files, nothing sent to a server. It would also expose a few tools over MCP (next_task, report, needs_human, check_live), so Claude Code or Cursor can call it directly. If you want to see how an MCP-connected agent is wired together, the AI Agent Developer Roadmap has chapters on MCP and tools.

It will be free, with a $0 listing on Gumroad so we can send updates, and the code public on GitHub. We will ship a first batch of verified playbooks, not all 393. Quality is the whole bet here, and we would rather be right about 40 directories than guess at 393.

What to do today, without any of it

• Pick ten, not three hundred. Start with directories that fit your product's audience.
• Check the link type. Open your listing after approval and see whether it is followed or nofollow. A nofollow link from a directory with real visitors is still worth having.
• Skip the zero-review ones. If a site approves anything instantly, ask why.
• Keep a log. Even a spreadsheet with directory, date submitted, status, and live URL beats memory.
• Measure after. DR going up is not the same as customers arriving.

If you want the kit when it ships, email shreyvijayvargiya26@gmail.com with the subject line "Directory kit". If you just want the table, log in on the directories page. The monthly iHateReading Magazine also carries a directories section.

More to come in the next one.

Cheers, ShreyZ