DEV Community: CodeLong888

Is your launch-site backlink actually dofollow? I checked 24 platforms

CodeLong888 — Sat, 10 Oct 2026 01:15:47 +0000

Every launch site promises you a backlink. Fewer of them say what kind.

I wanted to know what you actually get, so on 10 October 2026 I opened a live listing page on 24 launch and directory sites and read the rel attribute on the link that points at the listed product. Nothing fancy, just the HTML the server sends.

Disclosure up front: I run yourhack.ai, which is one of the sites in the comparison. Our own listing links are nofollow by default and turn followed when you link back or pay, so I'm not pretending to be neutral, just showing my working.

What I found

On the 23 sites where I could read the markup:

13 served a plain, followed link on the listing I opened
9 used rel="nofollow"
1 used rel="ugc" (Product Hunt, from my July check; it blocked my requests this time)

The more interesting part is how many "dofollow" promises come with a condition attached:

Site	Free link	The condition
DevHunt	nofollow	Their FAQ: "Links on free listings are nofollow; paid launches get a permanent dofollow link."
Uneed	followed, conditional	Free plan ties the dofollow link to an upvote score of 20
OpenHunts	nofollow on 2 of 3 listings	"Dofollow backlink if top 3" on the free tier
Open Launch	nofollow	Free tier lists two conditions for dofollow: a top 3 daily ranking and displaying their badge
TinyLaunch	followed on the pages I opened	Free tier promises a backlink only for top 3 products
Peerlist Launchpad	couldn't read it (client-rendered)	Their FAQ: only the top 5 projects of the week get a backlink
Show HN	mostly nofollow	27 of 29 titles on /shownew were nofollow; the one I opened from /show was not
Fazier	followed on paid launches	Free tier requires a link back to Fazier on your site

So "free dofollow backlink" very often means "free, if you win, pay, or link back". That's a fair trade, it just isn't the headline.

Check it yourself in 10 seconds

Open your listing, view source, and search for your domain. Or from a terminal:

curl -sL "https://example-directory.com/your-listing" \
  | grep -oiE '<a [^>]*yourdomain\.com[^>]*>'

If the tag has nofollow, ugc or sponsored in its rel, search engines are asked not to count it as an endorsement. No rel, or only noopener / noreferrer, means it's followed.

Two gotchas I hit:

Some sites render links with JavaScript, so the HTML from curl has no link at all. Crawlers often see the same thing on their first pass.
Redirect links. One site's "View tool" button points at its own short link that 302s to you with a ?ref= tag. The anchor itself had no nofollow, but it isn't a direct link to your domain.

A free checker, because I got tired of doing this by hand

I turned the check into a small free tool: Dofollow Backlink Checker. Paste the page that links to you plus your domain, and it lists every link to your site with its anchor text and rel, and flags pages that are noindex or nofollow as a whole.

Two siblings came out of the same work, for the day before you launch:

Social Preview Checker: how your link card looks on X, LinkedIn, Facebook and Slack, and which Open Graph tags are missing
Launch Readiness Checker: HTTPS, title, meta description, share image, favicon, viewport, H1, noindex, canonical and server response time, with a fix for each miss

The full comparison of all 25 sites (cost, account, link type and stated review time, with every URL I opened) is here: Where to submit your startup: Product Hunt alternatives compared.

The takeaway

A backlink from a launch site is a bonus, not the point. The same human visitors click a nofollow link as a followed one. Pick the two or three sites whose audience overlaps with your users, write a real description for each, and then check what you got instead of trusting the pricing page.

Where to list a vibe-coded app in 2026: launch sites compared

CodeLong888 — Thu, 01 Oct 2026 02:06:38 +0000

You built the thing in a weekend with Cursor or Lovable. Now you need somewhere to put it, and every "best launch sites" list you find is either two years old or written by one of the sites on it.

Disclosure first: I run VibeKing, which is one of those sites. On September 30 we went through 21 launch directories and wrote down what each one asks for, using only what the directory states on its own pages. This post is the short version of that guide. VibeKing is in the table too, and I'll get to it near the end. Nothing here is ranked.

Free is rarely free

Almost every launch site has a free tier. What changes is what you pay with instead of money. In practice it's one of three things:

Time. The free queue can be long. OpenHunts' free queue was about 60 weeks when we checked. Uneed assigns free launches a date that can be up to five months out. AlternativeTo says at least a few months.
A link on your site. LaunchIgniter, Smol Launch, Startup Fame, Fazier and Dang.ai all want their badge or a link back before the free listing counts.
Votes. Uneed needs an upvote score of 10 to keep a free launch published. Awesome Indie and Uneed both tie extra perks to 20 upvotes.

Neither is a scam. You just need to decide upfront which of these you can actually afford. A two-person team with a launch date can't wait 60 weeks. Someone with no audience will struggle on a board that runs on votes.

Free and immediate: Show HN, Product Hunt, Peerlist

These three cost nothing and don't make you wait.

Show HN has no queue and nothing to buy. The catch is in the rules: it has to be something people can try right now. Landing pages and waitlists get sent elsewhere. Drop the signup wall if you can, and stay in the thread to answer questions. That's half of what Show HN is.

Product Hunt is free, and you pick the day. Product Hunt's own advice is that the best day is "the day on which you're most prepared". It also says company accounts aren't allowed, so launch as a person. It's a same-day race, so it rewards people who show up with a network and spend the whole day replying to comments.

Peerlist Launchpad opens every Monday. It needs a verified Peerlist profile, so it suits you best if you already have one.

If your app is usable today, start here. Most vibe-coded apps are small, free and quick to try, and that's exactly what these three reward.

The cheap paid tiers

If you need a date and can't wait in a queue, the one-time tiers are cheap. These were the listed prices on September 30:

Directory	Cheapest paid option	Free tier, as stated
OpenHunts	$9.90 Premium ($19 list)	~60-week queue, or add their badge
LaunchIgniter	$12 Basic	date not guaranteed, badge required
Uneed	$14.99 Fast-track ($29.99 to pick your date)	up to 5 months
BuiltByIndies	$15 Premium	next launch week with space
Smol Launch	$19 Premium	50 verified slots a week, badge required
Fazier	$29 Lite ($39 list)	within 30 days, link required
Launch Llama	$39 Instant Launch	about 4 weeks
TinyLaunch	$39 Premium	"standard queue"
Microlaunch	$39 with code ($49 list)	not stated
DevHunt	$49 paid launch	not stated

Two more are priced like subscriptions: SaaSHub's featured listing is $99 a month, and Startup Fame's Highlight is $19 a month. AlternativeTo has a $5 priority review, but it doesn't guarantee approval.

Spending $10 to $40 to skip a five-month wait is often a reasonable trade. Spending $99 a month on a side project with no revenue usually isn't.

Match the site to what you built

This matters more than price, and it's the part most lists skip.

DevHunt only takes developer tools.
There's An AI For That and Dang.ai are for AI tools. TAAFT has no free tier; review costs $49. Dang.ai's free tier can take up to 4 weeks and wants a link back.
SaaSHub and AlternativeTo work best when your app replaces something people already search for ("alternative to Notion"). A brand-new category won't get much from them.
BetaList explicitly rejects vercel.app, netlify.app and herokuapp.com URLs.

That last one catches a lot of vibe-coded apps. If yours still lives on a free subdomain, buy a domain before you launch anywhere. It costs about as much as one paid launch, and whatever you earn from listings then points at something you own.

Read audience numbers as marketing

Some directories publish their reach and most don't. The ones that do are self-reported: There's An AI For That says 5M+ monthly users, Uneed says 90K monthly visitors and 26,000 newsletter subscribers, and Microlaunch says 30k+ unique visitors a month. Launch Llama's pricing page quotes two different newsletter sizes for the same list. I'm not saying any of these are false. They're marketing numbers, so give them the weight you'd give any marketing number.

Where VibeKing fits

VibeKing is a free directory for indie and AI-built apps and side projects. It has about 2,600 listings right now. A person reviews every free submission, usually within a few days. After that, the listing goes live once you add a small badge to your site, so it's in the "link on your site" group above. If you don't want the badge or the wait, there's a one-time Fast Track at $29 (a launch price; it goes to $99 later) that goes live straight away.

I'm obviously biased. Treat it as one more stop in the queue phase, not a replacement for Show HN or Product Hunt.

A plan that doesn't eat your month

Before anything: a custom domain, a version people can try without a signup, and a quick check of your homepage basics.
Launch week: pick one big free launch, Show HN or Product Hunt, and actually be there all day to answer people.
Same week: join two or three free queues that match what you built. They'll come up over the next weeks and months, which beats one spike that drops to zero by Thursday.
Only if you need a date: pay for one cheap tier, not five.
After launch: open your own listing pages and check they're live and say what you think they say. Directories change their terms, and the listing you got may not match the pricing page you read.

Prices and queues move every month. The full table, with a separate guide for each directory and links to its sources, is at vibeking.fun/launch. It's dated, so check the date before you rely on any number.

I gave a new AI model my browser racing game and one sentence: "make it AAA quality"

CodeLong888 — Wed, 02 Sep 2026 16:59:24 +0000

Four days ago my side project mylambo.money got a browser racing game: a 3D supercar with 25 ad panels, and a one-lap race where you start last against the projects on the leaderboard. It worked. It also looked like a tech demo.

Today I opened Claude Code on the new Claude Fable 5.1 model and typed one sentence: "make it AAA quality." I did not write a line of code. This is what happened, with the numbers from the session.

The starting point

One file, race.js, 2,028 lines, vanilla ES modules, three.js r180 vendored, no build step (it is a Cloudflare Pages site).
8 rivals on rails. No collisions, no AI.
The player car was a point with a heading and a speed. No slip, no body roll. The wheels did not even spin: the hook was called every frame but nothing ever set it.
A text 3-2-1 countdown, while the start gantry had five red lights modelled on it that were never used.
One synthesised music loop, no engine sound.

What the model did first: split the file

Before touching a feature it refactored the one file into 14 modules, none over 800 lines, with a shared state object and an events bus as the contract between them (physics, rivals, camera, audio, fx, env, hud, track, and so on). Then it spawned five agents, four of them in parallel, one per module group. The four that finished reported 865,875 tokens between them. The fifth hit the account's session limit mid-sentence; its last log line was "Now I have the full picture. Let me make the track.js changes first." It came back three hours later and did.

Nothing could be checked in a browser during the build. Headless Chrome software-renders WebGL on the CPU and has frozen this machine before, so every module was verified with node --check, an import resolver, and a node harness that mapped three to the vendored build and drove the real physics through full laps. 37 assertions for the car, 173 for the seams between modules (a second harness that mounts the real game entry with a stubbed DOM and runs two races, mute, resize, close and re-mount).

The car

Velocity-vector physics instead of a point: lateral grip that turns slide into forward speed, a handbrake for drifting (Space), six gears with a torque dip on upshift, nitro (Shift) that refills in a slipstream.
Wheels that actually spin and steer. This took measuring the glTF: the wheel nodes are empty groups with the hub at the origin, the tyre is 0.768 m in diameter, and the front axles are yawed 30 degrees in the asset, so each wheel gets a pivot that undoes that before it spins.
Body roll and pitch on a pivot under the car, so the 25 sponsor plates lean with it.
A clean lap is about 15.6 seconds. The scoring API refuses anything under 9, and it was not touched.

The rivals

Each rival is the same car flattened into four merged buffers (paint, trim, metal, lights), four draw calls instead of about twenty. They now brake for corners using the circuit's own curvature (a 900-sample radius table built once), change lanes to pass slower cars, block the player about 30% of the time when directly ahead, and rubber-band mildly so the field stays within sight. Pole still laps in about 16.1 s, so a clean lap from the back wins by a dozen metres.

The night

The first pass kept daylight, and my verdict when I saw the before/after video was blunt: I did not see any upgrade at all. Fair. The stadium was already there four days ago. So the second pass turned the sun off.

A pool of six spotlights re-targeted every frame to the six floodlight towers nearest the car (two on phones), with additive beam cones for all towers in one draw call, and pooled lens flares.
Two real spotlights on the player's headlights plus a painted road wedge, because 800-candela headlights blew out everything within 20 metres on the first try.
The reflection probe is baked from the venue itself with PMREMGenerator.fromScene once the track exists, so the floodlights reflect in the wet road and the clearcoat paint.
Wet asphalt: a puddle mask painted into the roughness map, with a specular cap injected through onBeforeCompile so the floods do not turn the road into a mirror at low camera angles.
Bloom with a threshold of 1.05. The 25 sponsor plates are unlit white and render at exactly 1.0, so every threshold below that made the car glow like a lamp. Real emitters are written above 1.0 instead.

The graphics agent could see its own frames: eight rounds of GPU screenshots through Playwright with --use-angle=d3d11, judging each one and fixing the four different ways the image went white before it landed.

Everything else

F1 start: five lights on the gantry, one per second, a random hold, lights out, with a camera sweep along the grid.
Slow-motion orbit at the flag, then a results screen with top speed, overtakes and a personal best kept in localStorage.
Engine, tyre squeal, wind, kerb rumble, gear clicks, overtake chime, crowd roar: all Web Audio synthesis, zero downloads.
Tacho with gear numeral, lap bar, gaps to the cars ahead and behind, overtake toasts, tilt steering and haptics on phones.
Tyre smoke, skid marks, sparks, speed lines, fireworks, confetti.

What I would tell you

It cost more than two million tokens across the agents and two rate limits, and the visible difference was not the physics or the sound. It was turning the lights off. If you are going to have a model rebuild a game, decide what the screenshot should look like first; the feel is invisible in a video.

The race is live and free, no account: mylambo.money/race. The car model is the Khronos glTF Sample Assets CarConcept, CC BY 4.0.

An OpenAI flagship lost 38% of its daily usage in three days — then set three straight all-time highs

CodeLong888 — Sun, 16 Aug 2026 01:41:04 +0000

Everyone publishes AI model leaderboards. Almost nobody publishes the day-level curve — and the
curve is where the actual story is.

At whatstrending.ai we snapshot every model's daily request count
from OpenRouter's usage feed into a database, once a day, INSERT OR IGNORE — a row can never be
revised after the fact. We're 78 days in. Here is what openai/gpt-5.6-luna did over the last two
weeks:

Date	Requests/day
Aug 04	162.9M
Aug 05	180.8M
Aug 06	193.8M
Aug 07	210.8M
Aug 08	222.5M ← peak
Aug 09	209.6M
Aug 10	171.6M
Aug 11	137.3M ← floor: −38.3% off peak in 3 days
Aug 12	143.2M
Aug 13	157.3M
Aug 14	231.8M ← new all-time high, +47.4% in one day
Aug 15	237.3M
Aug 16	243.5M ← third consecutive all-time high

A flagship model shed more than a third of its daily traffic in three days, then won all of it
back — and more — inside the same week. Three consecutive days above the old peak as of Aug 16.

Why this isn't a data artifact

Three checks, run before writing this:

The whole table didn't move. The all-model daily total went 3.56B → 3.66B (+2.8%) on the day luna jumped 47%, and 3.70B → 3.73B (+0.8%) on Aug 16. Luna's share moved: roughly 4.4% → 6.5%.
Peers didn't dip with it. During luna's drawdown (Aug 09–11), deepseek/deepseek-v4-flash-0731 and tencent/hy3 were setting their own highs on the same days — so this is not a provider-wide trailing-edge reporting droop.
Rows are frozen at write time. Aug 14 read 231.8M on the day we collected it and reads 231.8M today. Nothing was backfilled or revised.

Why it matters

Monthly aggregates — which is what every public ranking shows — would have flattened this entire
event into "usage grew". The day-level series shows real flagship usage is far more volatile than
anything the leaderboards suggest: a −38% drawdown and a full recovery to new highs fit inside eight
days. If you're making routing, capacity, or "which model is winning" decisions off monthly numbers,
you're averaging away the actual signal.

The live, daily-updated version of this curve is here:
https://whatstrending.ai/models

Method: daily snapshot of OpenRouter per-day request counts, 100 models/day, 78 days and counting,
stored append-only (INSERT OR IGNORE) in Cloudflare D1.

We ping 2,587 vibe-coded apps every 6 hours. The 'AI apps die fast' narrative isn't holding up

CodeLong888 — Sat, 15 Aug 2026 07:57:35 +0000

Everyone "knows" vibe-coded apps are abandoned within weeks. Someone ships a weekend project with Cursor or Lovable, tweets about it, and the domain quietly dies when the trial credits run out.

I run VibeKing, a directory of products built with AI coding tools. A couple of weeks ago I added a liveness engine: every product in the catalogue gets an HTTP check every 6 hours, cycling through all of them continuously. No sampling, no estimates — every single URL, checked repeatedly, with failure counts.

Here's what the data actually says so far.

93.1% of them are up

Of 2,587 approved products:

Status	Count	Share
Live	2,408	93.1%
At risk (intermittent failures)	178	6.9%
Confirmed dead	0	0%

"At risk" means the checker has caught the site failing on recent checks but it hasn't sustained enough consecutive failures to be declared dead. "Dead" requires repeated failures over multiple checks — a bar nothing has cleared yet in the observation window.

Two honest caveats. First, this window is short — the engine has been running since early August, so this measures current availability, not long-term survival. The interesting numbers arrive in 6-12 months, and I'll publish those too, whichever way they cut. Second, there's a survivorship component: some products died before ever being catalogued, and those deaths aren't in the denominator. What this data can say is narrower but still useful: of the vibe-coded products visible enough to be catalogued, 93% are up right now — the wasteland narrative describes launches that never got noticed, not the ones that did.

What vibe coders build: tools for other vibe coders

Category distribution of the same 2,587:

Category	Count	Share
AI Coding	691	26.7%
Dev Tools	400	15.5%
Marketing	316	12.2%
SaaS	237	9.2%
Productivity	178	6.9%
Design	161	6.2%

42% of AI-built products are developer tooling. The community's biggest output category is tools for itself — the classic gold-rush-shovels pattern, visible in the data.

.com still wins, but the builder TLDs are a third of everything

TLD	Share
.com	46.7%
.ai	11.4%
.app	10.1%
.io	6.0%
.dev	3.0%

.ai + .app + .io + .dev together are 30.5% — nearly a third of vibe-coded products launch on a "builder" TLD. And still, when makers want to be taken seriously, they buy the .com.

Method, briefly

Catalogue: 2,587 approved products on vibeking.fun, collected from launch platforms and direct submissions
Liveness: HTTP checks in rotating batches every 6 hours via Cloudflare Workers cron; a product is "at risk" after repeated recent failures and "dead" only after sustained consecutive failures
Anti-bot handling: sites that block automated checks (401/403/405/429) count as alive — refusing bots is not being down
Nothing here is estimated. Counts are from the production database, queried today.

I'll re-run this in a few months when the longitudinal picture exists. If you want your product in the tracked set: vibeking.fun/submit — free, no signup wall for browsing, and the checker will keep an eye on your uptime for you.

Your hreflang says English-only. Does your language switcher agree?

CodeLong888 — Thu, 13 Aug 2026 19:51:06 +0000

I run a maintenance sweep over my own site every day. Yesterday it found 1,474 dead internal links that had been sitting there in plain sight, on 737 pages, and every automated check I had was green.

The cause is a bug class I have not seen written up, so here it is.

Two places encode "which languages does this page have"

A partially translated site has, whether you planned it or not, two independent answers to the question does this page exist in Chinese?

The <link rel="alternate" hreflang="..."> tags in <head> — what you tell crawlers.
The EN / 简 / 繁 buttons in your nav — what you tell humans.

Mine disagreed. The hreflang side was correct: a few page families on my site are English-only, so those pages emit an English self-reference and nothing else. There is even a comment in the source explaining why, because declaring an alternate that 404s poisons the whole hreflang cluster.

The nav switcher never got that memo. It was doing the naive thing:

// every page, unconditionally
`<a href="${basePath}">EN</a>
 <a href="/zh-cn${basePath}">简</a>
 <a href="/zh-tw${basePath}">繁</a>`

So on every English-only page, the two Chinese buttons pointed at URLs that do not exist. Click 简 on the API docs, get a 404.

Why nothing caught it

This is the part worth internalising. The bug survived because it fails every test you would think to write:

The pages are all 200. Uptime checks, sitemap validation, status sweeps — all green. The broken thing is a link on a healthy page.
The hreflang is correct. Any SEO audit that checks hreflang reciprocity passes.
The 404s are correct too. Those Chinese URLs should 404; the page genuinely does not exist in Chinese.
It is invisible on the pages you look at most. My homepage, tools, and guides are translated, so the switcher works perfectly everywhere I click during normal use. It only breaks in the families I never browse by hand.

Every component was individually correct. The defect only existed in the relationship between two of them.

The check that found it

Nothing clever. Take a page, extract every on-site href, and curl all of them — recording the status and the redirect count:

curl -s https://example.com/some-page \
  | grep -o 'href="/[^"]*"' | sed 's/href="//;s/"//' | sort -u \
  | while read -r p; do
      code=$(curl -s -o /dev/null -w '%{http_code}:%{num_redirects}' "https://example.com$p")
      [ "$code" = "200:0" ] || echo "$p -> $code"
    done

The num_redirects half matters as much as the status. 200:1 is a link that works but burns a hop, and a page full of those is a page slowly leaking crawl budget. I run this against one rotating page per sweep rather than crawling the whole site — cheap, and over a couple of weeks it covers everything that matters.

On the page I happened to rotate to yesterday, the API docs, it printed exactly two lines. Both were the language switcher.

The fix is not "add the missing pages"

The tempting fix is to generate the Chinese versions so the links resolve. That is how you end up maintaining machine-translated pages nobody reads, and — if they serve near-identical content — competing with yourself in search.

The real fix is to make the two sources of truth one source of truth. I already had a set listing the English-only paths, used by the hreflang generator. The switcher just needed to consult it:

const zhLinks = EN_ONLY_PAGES.has(basePath) ? '' : `
  <a href="/zh-cn${basePath}">简</a>
  <a href="/zh-tw${basePath}">繁</a>`;

On English-only pages the switcher now renders the EN button alone. 1,474 dead links gone; the rest of the site keeps its full switcher. Whenever a page family gets translated for real, adding it to that one set fixes the crawler signal and the human UI in the same commit — which is the actual win here.

Three things to take away

If two subsystems answer the same question, one of them is going to be wrong. Language availability, feature flags, pricing tiers — anywhere you have a "which of these exist" list, count how many places encode it.
Green status checks do not mean green links. A 200 page can be full of 404s. Check the edges of your graph, not just the nodes.
Audit the family, not a sample. Spot-checking would have found nothing, because the switcher works on most pages. Enumerating every link on one page found it in seconds.

The crawler-facing side of this is what I care about most, since AI assistants read my machine-readable site directory and follow whatever URLs it hands them. A dead link is not just a bad click — it is a citation you never get.

Go curl your own language switcher.

How to check if an IP is blacklisted (DNSBL), from raw DNS to one curl

CodeLong888 — Wed, 29 Jul 2026 13:35:06 +0000

Your emails start bouncing, or a website suddenly challenges every request from your server. Very often the reason is boring: your IP landed on a DNSBL and you did not know.

A DNSBL (DNS-based blackhole list) is a reputation database you query over plain DNS. Mail servers do this on every incoming connection. Spamhaus, SpamCop, Barracuda and a dozen others each run their own list, their own criteria, and their own delisting process.

The raw mechanic (it is just DNS)

To check an IP against a list, you reverse its octets and query them as a subdomain of the list's zone. Checking 127.0.0.2 against SpamCop looks like this:

$ nslookup -type=A 2.0.0.127.bl.spamcop.net

Name:    2.0.0.127.bl.spamcop.net
Address:  127.0.0.2

If the name resolves (typically to something in 127.0.0.0/8), the IP is listed. If you get NXDOMAIN, it is clean on that list. 127.0.0.2 is the standard test address that every DNSBL keeps permanently listed, which is why the query above always "hits" and is a handy way to confirm your resolver can reach a list at all.

That last part matters more than people expect. Some lists, Spamhaus in particular, refuse queries coming from big public resolvers like 8.8.8.8 or 1.1.1.1. You can query them and get nothing back, conclude "clean", and be wrong. If you script your own checker, query through your own resolver and treat "no answer" as unknown, not clean.

Checking a dozen lists with one request

Checking one list tells you little. An IP that is clean on SpamCop can be listed on UCEPROTECT or PSBL. To do it properly you loop over 10 to 15 zones, handle each list's return-code semantics, and handle the resolver problem above.

Or you let one endpoint do it. I run a free, keyless API that fans out the DNS queries server-side:

$ curl "https://hackmyip.com/api/blacklist?ip=1.1.1.1"

{
  "success": true,
  "data": {
    "ip": "1.1.1.1",
    "total_lists": 12,
    "total_checked": 10,
    "unavailable_count": 2,
    "listed_count": 0,
    "clean": true,
    "status": "CLEAN",
    "results": [
      { "name": "Barracuda", "zone": "b.barracudacentral.org", "listed": false, "status": "not_listed" },
      { "name": "SpamCop", "zone": "bl.spamcop.net", "listed": false, "status": "not_listed" },
      { "name": "Spamhaus ZEN", "zone": "zen.spamhaus.org", "listed": false, "status": "unavailable" }
    ]
  }
}

(Response trimmed; the real one returns all 12 lists: Spamhaus ZEN, Barracuda, SpamCop, Spam Eating Monkey, UCEPROTECT L1, Composite Blocking List, Invaluement, PSBL, Mailspike, Truncate, WPBL, and Suomispam.)

One honest detail I want to point out because most checkers get it wrong: notice total_checked: 10 versus total_lists: 12, and "status": "unavailable" on Spamhaus in that run. When a zone cannot be reached from the edge location serving your request, the API says so instead of silently reporting "clean". If you build on top of this, treat unavailable as "check this one another way", not as a pass.

There is also a browser version of the same check at hackmyip.com/blacklist if you just want to paste an IP and look, and the full endpoint list lives in the API docs. No key, no signup, CORS enabled, so you can call it from a frontend too.

If your IP is actually listed

Fix the cause first. A listing almost always has a reason: a compromised machine on your network, a web form being abused to send mail, an open relay, or a neighbor on the same shared IP range. Delisting without fixing the cause gets you relisted fast.
Then go to each list's own delisting page. There is no central authority; every list has its own form and its own rules.
Some lists age entries out automatically after the abuse stops, others keep you until you ask. Recheck after a day or two.

If you are on a cloud provider or CGNAT, you may simply have inherited a previous tenant's reputation. Same playbook applies, and it is a good argument for checking an IP before you build anything mail-related on it.

how i run a 2,500-page directory from a single cloudflare worker

CodeLong888 — Tue, 21 Jul 2026 03:01:26 +0000

quick build writeup, because i haven't seen many people run a directory this way and it's been surprisingly nice to live with.

the site is vibeking, a directory of vibe-coded products (stuff people built mostly by prompting AI). around 2,500 entries right now, each with its own page, and the whole thing runs as ONE cloudflare worker with a d1 database behind it. no framework, no build step, no origin server. here's how it works and the two things that bit me.

one entry, not one page. the trick that makes a big directory maintainable is you never build pages, you build data. every product is a row in d1 (name, tagline, url, category, tags). one render function turns any row into a full page: title, meta, og tags, json-ld, internal links to related products, all of it. so the 2,000th product costs the same effort as the 5th. the worker matches /product/:slug, pulls the row, renders. that's basically the whole architecture.

d1 at the edge is great until you think about it wrong. it's sqlite, and for a read-heavy directory that's perfect. the mistake i made early was doing too much per request. put indexes on whatever you sort/filter by (category, votes, created_at) on day one, not after it's slow.

now the two things that actually bit me, because this is the useful part:

1. the soft-404 that quietly poisons your seo. my worker had a catch-all that, for any path it didn't recognize, just served the homepage with a 200. felt harmless. it is not. google crawls a bunch of guessed/junk urls, every one returns 200-homepage, and google decides "this site returns the same page for everything" and starts distrusting your urls. for a directory whose entire seo bet is thousands of unique pages, that's poison. the fix is boring but critical: any unmatched path must return a real 404. probe your own site with a fake url and confirm you get a 404. i'd fixed this on a couple of my other sites and STILL had to catch it here.

2. the cold-start problem is real and your page count doesn't save you. here's the humbling bit. i thought 2,500 pages was a moat. it isn't, on its own. a brand-new domain with 2,500 thin pages is 2,500 pages google mostly ignores, because you haven't earned trust yet. page count is potential energy, not traffic. what turns it on is the slow stuff: real internal linking, genuinely useful individual pages, being something an AI assistant would recommend, and earning a few real links from outside. i'm in the middle of that part now and it's the opposite of fun, which is probably why it's the part most of us skip.

if you're building anything directory-shaped on workers, those are the two i'd save you: return real 404s, and don't mistake a big sitemap for traction.

the site if you want to see the pattern in the wild: vibeking.fun. happy to answer anything about the worker/d1 setup in the comments.

thanks for reading.

I built 1,081 free tools. Today a stranger finally asked to join.

CodeLong888 — Sun, 19 Jul 2026 16:59:01 +0000

Seventeen days ago I launched yourhack.ai, a directory of free, client-side web tools. Calculators, converters, formatters, PDF stuff. Everything runs in the browser, nothing gets uploaded, no signups.

I kept adding tools almost every day. The counter says 1,081 now, which sounds impressive until you realize a counter is just me talking to myself. A directory you fill yourself is a monologue.

Today that changed. A stranger submitted their own product through the submit form and asked to be listed.

Why this tiny event matters

Nobody submits their product to a site they think is dead. A submission is someone spending their own effort betting that being on YOUR page is worth something. You cannot fake that signal, and you cannot buy it, which makes it the first piece of real product-market evidence a directory can get.

One submission is a small number. But the difference between zero and one is the difference between "my project" and "a place". Everything after this is just more.

What I actually did with it

I did not auto-approve it, and honestly that surprised me too.

The submission described itself as a free calculator. I opened the site: the calculator was behind a $4.99/mo plan, and the free part was a reference library. Decent product, but the listing copy oversold it. So I rewrote the listing to match reality (free library, paid tools, affiliate links disclosed) before approving it.

That felt like the actual job of a directory. Anyone can aggregate links. The only thing that makes a directory worth listing on is that someone checks what's behind the link.

The boring lessons

Review flows get used before you're ready. I wrote the submission form in week one and assumed it would sit idle for months. Real usage always arrives before the polish does.
The first outside user finds your real bugs. Mine surfaced a policy question I had never written down: can makers edit a listing after approval? (Answer now: no. Approved listings are frozen; edits go back through review.)
Ship the door before you expect visitors. If the submit form had not existed, this person would have bounced and I would never have known anyone cared.

If you run a directory, a gallery, a showcase, anything with a "submit" button: the day that button gets pressed by someone you don't know is the day the site becomes real. Build the door early.

The directory is at yourhack.ai, and if you've built a free web tool, the door is at yourhack.ai/submit.

i built 1000+ free web tools in a couple weeks and turns out building it was the easy part

CodeLong888 — Fri, 17 Jul 2026 11:20:35 +0000

so i've been building this thing called yourhack.ai for the last couple weeks and i wanted to write down the honest version of how it's going, mostly because everything i read about side projects is either a flex or a "how i hit $10k MRR" thing and this is very much neither lol.

it started dumb. i kept needing quick little tools online, convert this file, format this json, compress this image, count these words. and every single time i'd land on some site absolutely drowning in ads and popups, half of them making you create an account just to download the result of a 10 second task. it genuinely irritated me every time.

so i built one. a clean little tool that does the thing and gets out of the way. then i built another. and uh, i didn't really stop. it's over 1000 now.

the thing that let it get out of hand this fast is honestly the only clever bit: i don't build pages, i build entries. every tool is basically one object in a file (name, description, a little render function), and a template turns that into a full page with its own url, seo tags, structured data, search entry, all of it. so adding the 500th tool costs about the same as the 5th. the whole site is a single cloudflare worker at the edge, and most of the tools run entirely in your browser so your files just stay on your machine (the newer ai-powered ones do hit a server, being upfront about that).

anyway, that's the part i'm proud of. here's the part that's been humbling me.

i genuinely, kind of embarrassingly, believed that if i just made enough actually-useful stuff, people would find it. that was the whole plan. make it good and they'll come.

they did not come lol.

turns out a brand new domain is basically invisible. you can ship a thousand genuinely useful pages and google will just not care, because your site hasn't earned any trust yet and trust is the whole game. i had it backwards. i thought building was 90% of it and getting the word out was some small thing at the end. it's the opposite. building was the easy part, the fun part, the part fully in my control. distribution is slow and awkward and mostly out of my hands, and i'm just not naturally good at it.

and the embarrassing tell is what i keep doing about it: instead of doing the scary distribution work, i just build more tools. because building is comfortable and putting myself out there is not. i'm aware it's a cope. i've been doing it anyway. writing this is me trying to break the pattern a little.

where i've landed for now is to stop trying to "launch" and just be genuinely useful over a long stretch of time. answer real questions clearly, make the site something an AI assistant would actually recommend when someone asks it for a tool, and let that compound slowly instead of chasing a spike that dies in two days.

so that's the honest state of it. i can build fast, i'm bad at getting seen, and i'm working on the second one.

if you've been through this, i'd genuinely love to hear what worked for you. not "post everywhere", i mean the specific one or two things that actually moved the needle. if you want to see the thing itself it's yourhack.ai, though honestly i'd take the distribution advice over the traffic.

thanks for reading this far.

I tracked every trending AI repo's stars daily for 3 weeks. The growth is not where I expected

CodeLong888 — Fri, 10 Jul 2026 00:38:14 +0000

I run a small AI trends site, and three weeks ago I started doing something simple: every day, snapshot the star count of every repo that crosses my GitHub trending scan for AI. No judgment, no curation, just append-only rows in a database.

611 repos and 2,671 data points later (June 19 to July 10), the picture of what's actually growing looks pretty different from what my feeds told me was hot. Here's what the data says.

Before publishing this I re-checked every number below against GitHub's live API. Star counts drift by the hour, so treat them as of July 10.

The top 10 risers, by raw stars gained

Repo	Gained	Window	From → To
calesthio/OpenMontage	+30,253	21 days	5,899 → 36,152
DeusData/codebase-memory-mcp	+20,483	19 days	7,516 → 27,999
mattpocock/skills	+19,053	15 days	137,485 → 156,538
obra/superpowers	+16,887	20 days	232,908 → 249,795
NousResearch/hermes-agent	+14,896	21 days	197,297 → 212,193
Panniantong/Agent-Reach	+14,334	14 days	34,780 → 49,114
usestrix/strix	+13,243	12 days	26,363 → 39,606
addyosmani/agent-skills	+12,685	21 days	63,156 → 75,841
asgeirtj/system_prompts_leaks	+11,720	21 days	43,415 → 55,135
msitarzewski/agency-agents	+11,055	10 days	118,241 → 129,296

Windows differ because I only hold snapshots for the days a repo appeared in my scan; each row states its own real window.

Three things in this data genuinely surprised me.

1. "Skills" are eating agent frameworks

Four of the top ten are not agent frameworks. They are collections of packaged expertise that plug into an existing agent: obra/superpowers (still compounding at roughly 840 stars a day on a 250k base), mattpocock/skills, addyosmani/agent-skills, msitarzewski/agency-agents.

A year ago this table would have been full of new frameworks. Now the framework layer looks settled and the growth is in what you load INTO the agent. The moat moved from orchestration code to encoded judgment.

2. The sharpest climbs are applications, not infrastructure

The steepest sustained climb from a newcomer in my dataset is MadsLorentzen/ai-job-search: +10,591 stars in 3 days, roughly 3,500 a day. It is an AI job application framework. Not a model, not a devtool.

Same pattern elsewhere: OpenMontage (agentic video production) went 6x in three weeks and topped the whole table. xbtlin/ai-berkshire, a Chinese-language value-investing research agent, went from 1,518 to 12,339 in 15 days, an 8x. People are starring things that do a job for them, not things that help them build things.

3. A 14-year-old repo gained 10k stars in two days

smicallef/spiderfoot was created in April 2012. It is a classic OSINT automation tool. Between my June 21 and June 23 snapshots it gained 10,413 stars, the fastest burst I recorded from any repo.

Old tools that happen to be perfect agent tools are getting second lives. If your decade-old project has a clean CLI and does one thing well, it is suddenly relevant again, because agents can drive it.

Methodology, honestly

Snapshots are daily and only cover repos while they appear in my trending scan, so tracking windows differ per repo. Every delta above states its own window, measured between my first and last snapshot for that repo.
"Gained" is the difference between those two snapshots, no extrapolation.
I cross-checked the endpoints against GitHub's API on publish day; stored values matched within normal hourly drift.

The live version of this table updates daily on the rising repos page, and there's a daily AI briefing built from the same tracked data (model usage movers, funding, and rising repos), archived per day.

I'll keep the snapshots running. If this is useful I can post the four-week edition with week-over-week velocity, which the raw data already supports.

I put 300+ free web tools in one place, with no ads and no signup

CodeLong888 — Fri, 03 Jul 2026 01:51:49 +0000

I use a lot of little web tools. A JSON formatter here, a cron parser there, a "cm to inches" when I am reading a spec written by someone on the other side of the planet. And every single time, the same friction: the first result is buried in ads, a cookie wall pops up, and half of them want me to sign in just to format some text.

So I built the thing I actually wanted: yourhack.ai, a directory of 300+ free web tools. No ads. No signup. Nothing you paste ever leaves your browser.

What is in it

A bit of everything, all client side:

Developer: JSON formatter, Base64, JWT decoder, regex tester, cron parser, hash generators, diff checker, timestamp converter
Converters: length, weight, temperature, and dedicated pages for the pairs people actually search, like cm to inches and kg to lbs
Calculators: mortgage, loan, percentage, BMI, GPA, and a pile more
Generators: passwords, QR codes, UUIDs, fake data, usernames
PDF and image: merge, split, compress, resize, crop, all in the browser
Random and fun: dice, wheel of names, and the rest

Every tool is its own page, works offline once loaded, and runs entirely on your machine. A privacy-friendly toolbox by default, because there is no server to send your data to.

The part I actually enjoyed building

The whole site is one Cloudflare Worker with a tiny registry. Adding a tool is one object:

{
  id: 'json-formatter',
  name: 'JSON Formatter & Validator',
  category: 'developer',
  description: 'Format, validate and minify JSON in your browser.',
  keywords: ['json formatter', 'json validator'],
  intro: 'A short SEO paragraph for the page.',
  render: () => `<the self-contained tool HTML + inline script>`
}

The router, the shared template, the SEO tags, the JSON-LD, the sitemap, and the search index all read from that array. So the marginal cost of tool number 301 is one entry: no new routing, no new template. That is what made it possible to grow past 300 without the codebase turning into spaghetti.

No backend, no database, no build step. Static render on the edge plus inline JavaScript per tool. It costs almost nothing to run, which is the whole reason it can stay free with no ads.

Try it

It is live at yourhack.ai. Light and dark mode, mobile friendly, and it grows every day.

If there is a tool you keep googling and hate the ad-choked result for, tell me and I will add it. That is genuinely the roadmap right now: whatever people keep needing.