A post that stuck with me this week was someone who built a backlink directory called everybacklink. The story behind it is familiar: they saw a claim going around that you could point a bot at a link library and have it post backlinks on a schedule, and a brand-new site would climb to DR10 in a bit over a week. That outcome is unverified, and I'd treat it as marketing until someone shows the before-and-after. But the frustration that pushed them to build was real and worth copying.
The problem they hit wasn't a shortage of lists. It was that every awesome-list and giant spreadsheet out there is hard to actually use. Dead links pile up. You can't tell which sites are free, where the submission form is, or what hoops you have to jump through. As they put it, those tables are painful for a human to read, let alone to feed to a bot. So they had an agent spend a day compiling one, and shipped a directory: 509 submittable sites, sorted into categories like AI tool directories, SaaS directories, publishing platforms, communities, blog platforms, and developer platforms. Of those, 214 are free or have a free plan, and the whole thing filters by price and category. Each site lists its submission entry, requirements, and steps.
The part worth stealing
Here's the thing most people would miss. The valuable, reusable half of that project is not the scraped 509-site list. Lists rot. The reusable half is the shape of the data and the two faces it presents.
They built it so a person can browse and filter in a web page, and separately so a bot can read clean per-record feeds — they exposed `/llms.txt`, `/llms-full.txt`, `/api/sites.json`, and a standalone `.md` per site. The idea is you hand the links to your agent, it reads them, plans an order, and works through submissions day by day. For manual submitters, there's a local mark-as-done that lives in the browser with no signup. The data's released under CC BY-NC 4.0.
Strip away the specific topic and you've got a pattern that shows up everywhere right now: one curated catalog, two consumers. A human needs to skim, filter, and decide. An agent needs structured records it can parse without guessing. You see the same instinct in that Roadster game collection someone assembled — 21 entries, trilingual, a free browse page with sources preserved — and in the GridCraft hosting entry where the maintainer is careful to document scope and limits as actual data, not vibes. The common signal across all of it is people building small, curated catalogs and being honest about what's confirmed versus still being checked. That honesty is itself part of the data model.
Rebuilding the split on VicroCode
If I were rebuilding this pattern, I'd stop treating the dataset as a frozen export and treat it as a living store I correct by hand. The everybacklink author admits roughly half the prices aren't verified yet, and the dofollow/nofollow status on a chunk of sites is still being checked. That's not a flaw, that's the normal state of a curated catalog. It means you need something you can edit record by record as you confirm things.
Start with a single table. Columns for name, category, URL, submission entry, requirements, steps, price, free/paid flag, and a dofollow field you can leave null until you've checked. On VicroCode you can keep this in SQLite and correct it directly with the SQLite editor — flip a paid flag, fix a price, fill in dofollow once you've verified it, without redeploying anything. That hand-correction loop is the whole game. The data is only as good as how easily you can keep fixing it.
The bot-facing feed is a small Python service. One endpoint that takes a category and a free/paid filter and returns the matching records as JSON, and the same query rendered as markdown for the agents that prefer reading prose. You can run Python online against the SQLite file and host it as an API endpoint, so your agent hits one URL, gets back a clean filtered list, and plans from there. Keep the response flat and predictable — an agent parsing your feed should never have to scrape HTML to find a submission URL.
The human side is the same data, different surface. A browse page that reads the catalog, offers the free/paid toggle and category filter, and lets someone mark sites locally as they go. You can run HTML online for that view and point it at the same store the endpoint uses, so the two faces never drift apart. One source, two readers.
Where the boundary actually is
This is the part to be straight about with yourself. VicroCode can host the catalog, the filter endpoint, and the browse page. It cannot go submit your site to 509 external directories. The actual posting — logging into third-party forms, solving whatever each site demands, verifying days later whether a link came back dofollow — happens off-platform, in your agent's execution environment and on the target sites themselves.
So the realistic scope is: VicroCode is where the curated data lives and gets served, cleanly, to both people and bots. The submission work and any verification of outcomes sits outside it. If anyone promises you ranking results from this, that's unverified too — the only thing you control here is the quality and structure of the catalog, not what external sites do with your submissions.
That's still a genuinely useful thing to own. A catalog you can hand-correct, serve as structured records for an agent to plan from, and present as a filterable page for yourself, all backed by one store. The list part will go stale no matter what. The split — the data model and the two feeds — is what keeps paying off.