LaunchRepoA coding agent works from your repository and your files and can drive a real browser; a browser agent clicks through web pages but keeps little memory of your product or of what “done” means on each site; a done-for-you service does the work for you and sends a report. All three can get a SaaS listed on a few dozen directories. They are usually compared on price, yet what decides the choice is what each one needs from you, who holds the accounts, and what you own when the batch is finished.
This article spells that out, with a decision path at the end. It is written by the team behind the first option, so it tells you plainly where a service is the better answer.
Option 1: your coding agent
A coding agent — Claude Code, Codex, Cursor’s agent or a similar tool that reads a repository and calls tools — becomes a submission engine when you give it three things: a browser it can operate, your product facts in files it can read, and per-directory instructions that say what the form wants and when to stop.
What it needs. Git and Python 3.10 or newer for the local tracker and dashboard. The current Chrome, Node.js LTS and npm for the browser connection: the kit uses Chrome DevTools MCP, which lets a coding agent “control and inspect a live Chrome browser”, attached to a Chrome you are signed in to and can watch. Your product facts in one file, your public identity in another, and a decision about which personal details may appear on listings. Then one start prompt. The Chrome connection guide walks through the setup.
Cost model. You pay your provider for the agent’s usage and, with LaunchRepo, one payment for the repository. Your second product costs agent time, not a second licence, and there is no per-directory fee.
Control. Complete and visible. The agent works in your browser with your accounts. When a CAPTCHA, a two-factor prompt or a verification email appears, it records prepared_needs_human and you solve it in the same window. It never pays: a directory whose only route costs money is recorded as deferred_paid, and the decision stays with you. Every outcome lands in a local tracker with a date and, where one exists, a public URL.
What you own afterwards. The accounts, the listings, the tracker with real states, the playbooks and a workflow you can repeat next quarter or for the next product. Nothing lives on a vendor’s server.
Where it asks for effort. A one-time setup: browser connection, permissions and a first onboarding session. During a batch you stay within reach for handoffs. If you have never run an agent with a browser tool, plan the first hour as learning. The agent pages cover each setup: Claude Code, Codex, Cursor, OpenClaw, Gemini CLI, Cline, OpenCode, Kiro, GitHub Copilot and Windsurf, each checked against the tool’s documented browser and approval model.
Option 2: a browser agent
Browser agents, hosted or local, already do the clicking. Point one at a submission form, give it text, and it fills the form. That looks like option 1 but differs in one important way: by default a browser agent does not carry your product across sites and has no rule for what counts as finished on a given directory.
What it needs. The same product facts and identity, handed over per session, because a hosted browser agent cannot read your repository. A brief per directory: what the form asks, what counts as confirmation, what to decline. And a way to record results, since the agent usually cannot run your tracker.
Cost model. Usage billing from the agent’s provider, sometimes a subscription for the agent product itself, plus whatever supplies the briefs. The browser-agent page explains how the kit’s playbooks can play that role when the agent cannot read files. OpenAI has retired ChatGPT agent mode; what replaced it and how far it gets on a launch has its own dated page.
Control. High while you watch, lower when you look away. Without rules, a browser agent may click “Upgrade” when the free form sits behind it, submit twice after an unclear confirmation, or note “launched” after seeing a thank-you page. Those rules have to come from somewhere.
What you own afterwards. The accounts and listings, if you signed in yourself, and a record if you kept one. A session history is not a submission tracker.
Where it shines. Heavy, visual forms and one-off submissions where a repository would be overkill. It is weaker on batches of thirty platforms with follow-ups over several weeks, because that is a state-tracking job.
Option 3: a done-for-you service
You pay, fill in a form about your product, and a team — human, automated or both — submits it to a fixed number of directories and sends a report. This is the largest and most varied segment, and the right done-for-you submission service saves real time.
What it needs. From you: product facts, a logo, screenshots and sometimes access to an email address. From the vendor: a package choice. Account handling differs. Some vendors create a new email address and hand over the credentials, some use yours, and one we checked submits to directories that only offer Google sign-in “using our own Google account”. Read that part before you pay; the comparison pages quote each vendor.
Cost model. Usually a one-time fee per product or website, tiered by directory count; sometimes a monthly plan. On 30 September 2026 the one-time plans of the vendors we compare ranged from $60 to $999 per product. Your second product costs the same again.
Control. Low by design, which is what you pay for. You see a report at the end. Whether a listing used the free route, and whether “listed” means live or pending review, depends on the vendor’s reporting. Some deliver live links and screenshots, others a spreadsheet.
What you own afterwards. The listings that went live, and account credentials if the vendor hands them over. The next product is a new order. Some services promise a domain-rating level or a listing count; the directories still decide what they publish.
Where it is the right answer. One product, no interest in agents, and a budget. Then a service is a sensible choice, and the alternatives hub sorts the vendors by model so you can pick on facts.
The differences that decide it
| Coding agent + toolkit | Browser agent | Done-for-you service | |
|---|---|---|---|
| Who does the work | Your agent, in your browser | The agent, in its browser or yours | The vendor’s team or automation |
| Who holds the accounts | You | You, if you signed in | Vendor or you, per package |
| Price grows with | Agent usage | Agent usage | Number of products |
| Second product | Same repository | Same setup, new briefs | New order |
| Handoffs (CAPTCHA, 2FA) | Recorded, yours to solve | Yours, if you notice | Vendor handles or skips |
| Free vs paid route | Free by default, never pays | Whatever it clicks | Defined by the package |
| Record of what happened | Local tracker, 11 states | Whatever you kept | Vendor’s report |
| Afterwards | Playbooks, tracker, accounts | Accounts | Listings, report |
The “second product” row separates buyers. If you ship one product a year, the service column wins on effort and the price gap is small. If you ship several, or relaunch after a rename, the repository column wins on both, and the browser-agent column depends on how carefully you keep records.
A five-question decision path
Answer in order and stop at the first clear result:
- Do you want to touch the process at all? No: choose a service and compare vendors on account handling and reporting.
- Will you launch more than one product, or relaunch one? Yes: a coding agent with a repository pays off from the second run.
- Do you already use a coding agent in a terminal or editor? Yes: add a browser connection and the playbooks; you are most of the way there.
- Is it a single, visual, one-off form? Yes: a browser agent with a clear brief is quickest.
- Do you need a record of scheduled, pending and live entries for weeks? Yes: use a tracker, whichever option does the clicking.
What LaunchRepo is, in this frame
LaunchRepo is option 1, packaged: 299 active platform playbooks as of 24 September 2026, a product template, a tracker with eleven distinct outcome states and a local dashboard, in a private repository your own agent runs. It also serves as the rulebook that option 2 lacks, which is why the browser-agent page exists. It is not option 3: there is no managed team, only a repository and one price for every product you own.
So choose by what you want to own afterwards. If the answer is “just the listings”, pay a service. If the answer is “the process”, get the repository and hand it to the agent you already have.
Frequently asked questions
What is the difference between a coding agent and a browser agent?
A coding agent reads and writes files in a repository and calls tools, including a browser through an MCP server. A browser agent operates web pages directly but usually cannot read your files or keep state between sessions. For directory submissions, that state — product facts, rules and outcomes — is what matters most.
Can a browser agent submit to directories on its own?
It can fill and send forms. It needs outside help to know which route is free, what counts as a confirmation and where to record the result. With per-directory briefs and a tracker it works well; without them, results depend on how closely you watch.
Is a done-for-you directory submission service worth it?
For one product and no interest in agents, often yes. Check who creates and keeps the accounts, whether the report separates live from pending listings, and what happens with paid upgrades. The comparison pages list these points per vendor.
Do I need Claude Code to use LaunchRepo?
No. LaunchRepo needs an agent that can read files in a repository and drive Chrome through Chrome DevTools MCP. The agent pages describe Claude Code, Codex, Cursor and the others one by one; the kit recommends a CLI agent in a terminal for the smoothest run.
Who owns the directory accounts?
With a coding agent or a browser agent that uses your signed-in browser, you do. With a service, it depends on the package: ask before paying whether the accounts are created in your name and whether the credentials are handed over.
Sources: the LaunchRepo repository (START.md, BROWSER-SETUP.md, record.py with its eleven states) and catalog snapshot of 24 September 2026; the Chrome DevTools MCP README and Claude Code MCP documentation, checked on 30 September 2026; vendor pages checked for the comparison pages on 30 September 2026. No vendor was contacted for this article.