Forem: Jim L

5 + 1 Indie Web Projects I Built Solo in 2026 (AI Tools, Finance, Pet Care)

Jim L — Sat, 18 Apr 2026 02:23:29 +0000

5 + 1 Indie Web Projects I Built Solo in 2026

I'm Jim Liu, an independent developer based in Melbourne. Here are six side projects I've shipped solo over the last twelve months. None of them are VC-funded, all of them live under my own domain, and most were written on nights and weekends after day-job hours.

1. OpenAI Tools Hub — honest AI tool reviews

OpenAI Tools Hub is an opinionated review site for the current wave of AI coding and writing tools: Claude Code, Cursor, GitHub Copilot, ChatGPT, Windsurf, Warp, and a few dozen more. Each review has a "how we tested" section, a pricing table pulled monthly, and a short "who should skip this" paragraph — because not every tool is worth its ticket price.

It also ships ~36 free developer tools (LLM latency comparator, Claude-skills marketplace comparison, prompt cost calculator) at openaitoolshub.org/tools. Next.js 16, Cloudflare Workers, and a heavy bias against AI-generated listicles.

2. SubSaver — save money on subscriptions

SubSaver compares subscription prices across 30+ services (Netflix, Spotify, ChatGPT Plus, YouTube Premium, NordVPN, Adobe Creative Cloud) and shows how to get them cheaper through family plan sharing, annual billing, promo codes, and verified shared plans.

The core hypothesis: most people overpay for streaming and SaaS subscriptions by 40–70%. My job is to show the math, not to sell anyone a scheme.

3. LowRiskTradeSmart — low-risk trading research

LowRiskTradeSmart focuses on covered calls, LOF premium arbitrage, and Hong Kong bond yield analysis. Its HK bond yield comparator calculates 2026 iBond, Silver Bond, and Green Bond interactive yields from HKMA data. Multi-locale (EN / zh-CN / zh-HK).

4. AlphaGainDaily — covered-call and yield ETF insights

AlphaGainDaily tracks high-yield ETFs (YBTC / BCCC / BTCI / BAGY) and the newer wave of Bitcoin covered-call funds, including the Goldman Sachs Bitcoin Premium Income ETF (filed April 14, 2026). Plain-English weekly alpha analysis, no crypto moon-speak.

5. LevelWalks — puzzle game walkthroughs

LevelWalks is my lightest project — step-by-step walkthroughs and level guides for mobile puzzle games. Aimed at casual players who want a nudge, not a full solution leaked. Fun to build, occasionally catches a small burst of Google traffic when a new game trends.

+1: PawAI Hub — free AI tools for pet owners

Separately, I also run PawAI Hub — a free hub of honest pet-care tools for dog and cat owners. It has a dog food calculator (calories by breed / weight / activity), a cat age in human years calculator that drops the "× 7" myth in favor of the actual biological curve, an AI breed identifier (photo → top 3 guesses), an emotion reader that parses body language from a photo, and a training Q&A backed by an LLM with cited sources.

Built solo in the same stack (Next.js, Cloudflare Workers, D1, R2). No signup, no dark patterns.

Why post this here?

Because I see a lot of "portfolio indie hackers" posts on DEV and I've never written one for mine. If anything here resonates — especially the "review site with downsides admitted" approach from OpenAI Tools Hub, or the D1-runtime blog pipeline powering PawAI Hub — I'm happy to write a follow-up that goes deep on stack choices and what broke. Leave a comment and I'll pick the most-requested topic.

Not looking for traffic. Just putting names to projects.

5 Small Web Projects I Built as an Indie Developer in Melbourne

Jim L — Fri, 17 Apr 2026 02:35:18 +0000

I'm Jim, a Melbourne-based indie developer. Over the last year I've shipped five small web projects across AI tools, subscription management, Hong Kong investing, crypto research, and daily puzzle games. Here's a quick walkthrough of each, what problem it solves, and what stack it uses.

1. OpenAI Tools Hub

A free directory of AI tools with honest reviews and head-to-head comparisons. Covers ChatGPT, Claude, Cursor, GitHub Copilot, Midjourney, and 50+ other tools. Built as a Next.js 15 app on a VPS, with a Supabase-backed blog pipeline so I can publish new comparisons without redeploying.

Link: openaitoolshub.org

2. SubSaver

A subscription manager that shows you how to save on Netflix, Spotify, ChatGPT Plus, YouTube Premium, NordVPN, and 30+ other subscriptions through family plans, annual billing, and verified shared plans. Runs on Cloudflare Workers via OpenNext, with Supabase Postgres for the content tables.

Link: subsaver.click

3. Low Risk Trade Smart

Hong Kong ETFs, HK IPO strategies (打新), LOF premium arbitrage, and low-risk trading guides for Asia-Pacific investors. Trilingual (English, Simplified Chinese, Cantonese). Also a Next.js site, with a DB-driven catch-all route for the multi-locale blog.

Link: lowrisktradesmart.org

4. AlphaGain Daily

Daily crypto news, DeFi updates, macro research, and long-term portfolio insights. Covers Bitcoin, Ethereum staking, Solana, and the major L1/L2 ecosystems. Prisma + Postgres for the news feed, and a lightweight editorial workflow so I can post while reading my feeds in the morning.

Link: alphagaindaily.com

5. LevelWalks

A free daily puzzle and brain training platform featuring logic grid puzzles, word games, sudoku, nonogram, and a MindSort solitaire variant I built for seniors in my family. Cloudflare Pages + static JSON for levels and blog posts. Zero runtime server, which keeps latency and cost low.

Link: levelwalks.com

I'd love feedback on any of these — especially from other indie builders. What stacks are you running, and what do you wish I'd built differently?

How I Fixed 3 Cannibalizing Blog Pages — Real GSC Data + Next.js Fix

Jim L — Fri, 17 Apr 2026 01:41:22 +0000

Google Search Console flagged something odd on one of my Next.js blogs this week: three different pages were all ranking for the same keyword at positions 5 to 8 — but not one of them had a single click.

That is textbook keyword cannibalization, and it took me about thirty minutes to fix. The part I found interesting is that the fix is almost entirely at the content layer, not the technical layer. Next.js already gives you the tools you need — the question is whether your frontmatter and internal linking are doing what they should.

Here is the full walkthrough with the actual data.

What GSC Actually Showed

Pulling the queries report for the last 28 days and filtering to the problematic term, I got something like this:

URL slug	Position	Impressions	CTR
page-a	5.1	14	0%
page-b	5.2	12	0%
page-c	5.6	11	0%

For the same four-word query, Google was seeing three pages it thought were roughly equally relevant and none of them were clearly best. Searchers got confused, none of them clicked.

Meanwhile the same three pages had different keyword wins elsewhere:

URL slug	Winning KW	CTR
page-b	"X vs Y"	9.1%
page-c	"Z vs Y"	22.2%

So the pages themselves were fine. Each had a specific comparison angle that was working. The problem was the shared, broader keyword — they were all undifferentiated on it, and Google could not decide which to rank.

The Diagnosis (5 minutes)

Open each page's frontmatter. Look at the title and description. Do any of them look nearly identical?

Mine looked like this:

# page-a
title: "X Tools Hong Kong: Y vs Z vs W"
description: "X tools in Hong Kong compared. Y, Z, W fees, returns..."

# page-b
title: "X Tools Hong Kong — Y vs Z vs W Fees and Returns Compared"
description: "Hong Kong X tools comparison. Y 0.2-0.8%, Z 0.35-0.65%..."

# page-c
title: "Y vs Z Hong Kong: Which One Fits Your Style"
description: "Y vs Z vs W Hong Kong comparison. Fees 0.1-0.8%, honest downsides..."

Page A and B were nearly identical. Both listed Y, Z, and W in the title. Google saw them as the same intent page. Page C was doing better on its specific 2-way compare term (9.1% CTR) but the description still mentioned W, which pulled it into the broader three-way competition.

The Fix: Differentiate Intent, Don't Canonicalize

The first instinct is to add canonical meta pointing everything at one page. I decided against that for two reasons:

The pages have different specific-term wins (9.1% and 22.2% CTR on their own terms). Canonicalizing everything to page B would lose those.
Once you canonical a page, Google treats it like a duplicate and may stop crawling it meaningfully. Reversible but not cheap.

Instead: differentiate the titles and descriptions to match different search intents, and let internal linking consolidate topic authority on a pillar.

Page A became beginner-focused (new to the space):

title: "X for Beginners: Y's $0 Minimum, Z Core, and W Fund Smart"
description: "First-time X in Hong Kong? Y's $0 min, Z Core, W Fund Smart compared for beginners — plus when DIY is actually cheaper."

Page B became the pillar (canonical target for the broad term):

title: "X Hong Kong Comparison: Y vs Z vs W Fees, Returns, and MPF"
description: "Hong Kong X comparison, April 2026. Y 0.2-0.8%, Z 0.35-0.65%, W 0.25-0.6% — full fee stack, MPF integration..."

Page C stayed narrow (the 2-way compare winner):

title: "Y vs Z Hong Kong: Which One Fits Your Investment Style"
description: "Y vs Z Hong Kong head-to-head, April 2026. Fees from 0.1-0.8%, real portfolio allocations, ERAA vs Core philosophy..."

Notice the description change on page C — I removed vs W from the description. That single change narrowed the search-intent match so the page stops competing for the broad term.

The Internal Linking Piece

Differentiated titles are only half. The pillar page (B) needs to accumulate topical authority from the satellite pages (A and C). So I added a Related Reading callout at the top of A and C:

> **Want the full Hong Kong X landscape?** This article is a head-to-head between Y and Z only. For W added to the mix, see our [X Hong Kong Comparison](/en/blog/pillar-slug) pillar.

In Next.js markdown/MDX, this is just a standard link — remark-gfm handles blockquotes, and the <Link> component in your layout picks up internal URLs. No special config.

Two reasons this matters more than most people think:

It signals pillar intent to Google. When satellite pages consistently link to a specific page as the "full" version, Google consolidates ranking signals there.
It improves UX. Someone landing on page C who actually wanted the three-way compare now has one click to the pillar.

What I Did Not Do

I did not:

Change slugs (costs 301 redirects and rankings).
Add rel=canonical across pages.
Touch the sitemap.
Request reindexing manually (IndexNow handled it automatically — more on that below).

The fix is title frontmatter + description frontmatter + one markdown callout per satellite page. That is a 10-line diff per file.

Pushing the Fix Live

Next.js blog, deployed via GitHub Actions to a VPS. The commit was three file edits. CI ran in 5 minutes 36 seconds. Page built, deployed, verified with curl.

curl -s https://mysite.example.com/en/blog/pillar-slug | grep -oE "Hong Kong Comparison"

Returns the new title. Good.

IndexNow for Fast Re-crawl

One thing I did want: fast re-crawl, because Google's existing cached version of those three pages still showed the old titles. If a searcher saw the stale cached result, they would click based on old framing. I wanted Google to refresh those specific URLs today, not in two weeks.

IndexNow does this. It is a simple API supported by Bing, Yandex, and others (Google still does not endorse it but rumor has it they read the signals). The request is one POST with a key file at your root.

import requests

payload = {
    "host": "mysite.example.com",
    "key": "YOUR_KEY",
    "keyLocation": "https://mysite.example.com/YOUR_KEY.txt",
    "urlList": [
        "https://mysite.example.com/en/blog/page-a",
        "https://mysite.example.com/en/blog/pillar",
        "https://mysite.example.com/en/blog/page-c",
    ],
}

for endpoint in [
    "https://api.indexnow.org/indexnow",
    "https://www.bing.com/indexnow",
    "https://yandex.com/indexnow",
]:
    r = requests.post(endpoint, json=payload, timeout=20)
    print(f"{endpoint}: {r.status_code}")

Three endpoints, three 200/202 responses, done in under a second. Bing typically re-crawls within 24-48 hours. In my experience, Googlebot follows Bingbot traffic spikes surprisingly closely, so the effect often shows up indirectly within a week.

The Thing I Almost Missed

Before shipping, I triple-checked one thing: the page with the 22.2% CTR on its specific 2-way compare term. That was the best-performing page on the whole site for that angle. Canonical-ing it, changing its slug, or even over-editing its title could destroy that win.

So that page got zero changes except the Related Reading callout at the top. Description stayed the same. Title stayed the same. I only changed the other two pages' titles to deflect the broad-term competition away from it.

It is easy to over-engineer an SEO fix. Find the page that is working and leave it alone. Change the pages that are stealing its share.

Results Timeline

Position re-calibration on cannibalization fixes typically takes 2 to 4 weeks for Google to settle on which page wins for which intent. I will know by early May whether the pillar consolidates or whether the three pages re-split.

What I am watching in GSC:

Pillar page (B) impressions on the broad term — should go up
Beginner page (A) and specific compare (C) impressions on the broad term — should go down (by design)
Specific compare (C) on its 2-way term — should stay flat or go up slightly
Clicks on the pillar's CTR — should be the biggest win, from 0% to 2-5% range

If all four move that direction, the fix worked. If the pillar's impressions drop instead, something else is wrong — either the title is too narrow now, or the internal links need stronger anchor text.

The Takeaway for Next.js Devs

Keyword cannibalization is almost always a content-layer problem masquerading as a technical one. Most stacks give you what you need:

title and description in frontmatter
Internal linking via <Link> or markdown
Canonical URLs derived automatically from file path

The work is in the audit and the differentiation, not in the code. Read your own descriptions out loud — if two of them are answering the same question with the same words, Google is going to think the same thing.

Ten minutes of honest editing and your GSC report starts looking different in a month.

I Switched from LangGraph to Mastra for My TypeScript Agents — 18 Hours vs 41

Jim L — Thu, 16 Apr 2026 02:31:29 +0000

I spent three weekends in February trying to get a LangChain/LangGraph agent working in a Next.js app. By Sunday night of the third weekend, I had 41 hours logged, a mass of Python-to-TypeScript bridge code, and an agent that completed about 87% of what I threw at it.

Then a friend sent me a link to Mastra. Four days later, I had the same agent running natively in TypeScript. 18 hours total. No bridge code. No subprocess spawning. No serialization headaches between Python and my frontend.

I want to talk about what actually changed and where the rough edges still are.

The problem with Python agents in a TypeScript stack

My project is a multi-step research agent — it takes a topic, searches several sources, cross-references findings, and produces a structured summary. Standard stuff. The architecture is Next.js frontend, Vercel deployment, Postgres for state.

LangGraph is excellent software. The graph abstraction for agent workflows makes sense. But here's what nobody tells you upfront: if your entire stack is TypeScript, using a Python agent framework means you're now maintaining two runtimes, two dependency trees, two deployment pipelines, and a serialization layer between them.

I tried the LangChain.js port first. It's always a few versions behind the Python original. Some features exist in docs but not in the npm package. I filed two issues that turned out to be "not yet ported from Python." The community examples are 90% Python. Stack Overflow answers are Python. The mental overhead of translating between the two languages while debugging agent logic was genuinely draining.

So when I saw Mastra — TypeScript-native, built by the team that made Gatsby, YC-backed, sitting at around 22K GitHub stars — I figured it was worth a weekend experiment.

What switching actually looked like

Mastra's mental model is closer to how I already think about TypeScript applications. You define agents as objects with tools, instructions, and a model. Tools are just typed functions. Workflows (their equivalent of LangGraph's graphs) use a step-based API that chains with .then() and .branch().

Here's what surprised me: I didn't need to learn a new paradigm. The agent definition reads like a regular TypeScript module. The tools have Zod schemas for input/output validation — something I was already using everywhere else in the app. Type inference flows through the entire chain.

Rewriting my research agent took about 12 hours. The remaining 6 hours were spent on the retrieval pipeline (Mastra has a built-in RAG module with chunking and embedding support) and testing.

The part I dreaded most — the multi-step workflow where the agent decides which sources to query based on initial results — turned out to be simpler than the LangGraph version. In LangGraph, I had conditional edges between nodes, a state schema in TypedDict, and a routing function. In Mastra, it's a workflow with .branch() that returns the next step name. Both work. The Mastra version is about 60% less code and doesn't require me to think in graph theory.

The numbers that actually mattered

After running both implementations against my test suite of 200 research queries:

Task completion rate: Mastra agent hit 94.2% vs 87.4% with LangGraph. Some of this is probably down to me writing better tool definitions the second time around, so take the comparison with appropriate skepticism. But the type safety caught several edge cases during development that I'd missed in the Python version — malformed tool outputs that would silently pass in Python but threw compile-time errors in TypeScript.

P95 latency: 1,240ms (Mastra) vs 2,450ms (LangGraph). The LangGraph number includes the Python subprocess overhead and JSON serialization round-trips. Not a fair comparison of the frameworks themselves — more a reflection of what happens when you eliminate a language boundary. If you're running LangGraph in a pure Python backend, the gap would narrow considerably.

Deployment: This is where I felt the biggest quality-of-life jump. vercel deploy and you're done. 90 seconds. No Docker container for a Python runtime. No Lambda layer for dependencies. No cold start penalty from spinning up a Python process. It's just a Next.js app with some extra API routes.

Where Mastra is still rough

I'd be dishonest if I didn't mention the gaps.

The ecosystem is young. LangChain has integrations with seemingly everything — obscure vector databases, every LLM provider, dozens of document loaders. Mastra covers the major ones (OpenAI, Anthropic, Google, Pinecone, PGVector) but if you need something niche, you're writing a custom integration.

Documentation has improved a lot since I started, but there are still areas where I had to read the source code. The workflow error handling section, in particular, could use more examples.

The community is growing fast but it's a fraction of LangChain's. When I hit a problem at 11pm, there were maybe three relevant GitHub discussions. With LangChain, there would have been a dozen Stack Overflow threads.

And the agentic patterns — reflection, planning, multi-agent orchestration — are less battle-tested. LangGraph has been used in production by hundreds of companies. Mastra is getting there, but the edge cases in complex multi-agent setups are still being discovered.

Who should actually consider switching

If you're running a Python backend and LangGraph works for you, I see no reason to switch. The framework is mature and well-supported.

But if you're in the situation I was in — TypeScript stack, deploying to Vercel or Cloudflare, tired of maintaining a Python sidecar just for your agent logic — Mastra removes a real and ongoing source of friction. The 23 hours I saved on initial setup will compound every time I add a new tool or modify a workflow, because I'm working in one language instead of two.

I'm three months in now. The agent handles roughly 400 queries per day in production. I haven't regretted the switch.

Running TypeScript agents in production? I'm curious what framework you landed on and whether you hit similar Python-bridge problems. Drop a comment — genuinely want to compare notes.

How I built a LOF arbitrage monitor for HK/CN ETFs (and what I learned about 'free' alpha)

Jim L — Tue, 14 Apr 2026 01:22:05 +0000

I keep seeing the same question in HK/SG investor chats: "the S&P 500 QDII ETF is trading 5% above NAV again — is this free money?"

Short answer: not really. But the idea — that on-exchange ETF prices can drift from their net asset value — is real enough that I wanted a dashboard that just told me, every 15 minutes, which Chinese LOF/QDII ETFs were trading most disconnected from the underlying. So I built one.

This is the boring-but-useful write-up: what a LOF is, why premiums happen, what the pipeline looks like, and the three things I got wrong on the first try.

What's a LOF, quickly

LOF = Listed Open-Ended Fund. It's a mutual fund wrapper that also trades on-exchange. QDII LOFs are the ones that hold offshore assets — S&P 500, Nasdaq, HK tech, gold miners, etc.

The premium/discount mechanic:

NAV is published once a day (T+1 for offshore QDII — you get yesterday's value tomorrow morning).
On-exchange price moves live during the trading day.
When retail piles into, say, 华夏纳斯达克 after a big US overnight rally, the price can float well above the last-known NAV. That gap is the premium.
In theory, the fund house can issue new units to arb it down. In practice, QDII quotas are capped, so premiums can persist for days.

So: premium ≠ free profit. It's mostly "the market is front-running tomorrow's NAV update." But unusual premiums are worth watching, because that's where forced-selling and fat-finger trades show up.

The pipeline

Stack ended up boringly simple. Four moving parts:

Eastmoney REST  ─┐
                 ├─► Python collector (every 15 min, cron)
Tencent REST  ──┘          │
                           ▼
                     SQLite (append-only)
                           │
                           ▼
                Next.js /tools/lof-premium (ISR 15min)

No Kafka, no Redis, no Airflow. It's a 200-line Python script and a static-ish Next.js page.

Collector

The collector is two functions:

def fetch_realtime(code: str) -> dict:
    # 东财 push2 API, returns last price + bid/ask
    url = f"https://push2.eastmoney.com/api/qt/stock/get?secid={secid(code)}&fields=f43,f60,f169,f170"
    ...

def fetch_nav(code: str) -> dict:
    # 天天基金 fundgz API, returns "估值" (intra-day NAV estimate)
    url = f"https://fundgz.1234567.com.cn/js/{code}.js"
    # returns JSONP; strip the wrapper, json.loads the middle

One gotcha that cost me an afternoon: fundgz returns HTML on weekends and holidays (a friendly "市场休市" page) instead of the usual JSONP. First version crashed on every Saturday at 09:15 until I added a content-type check.

Why not just use one source?

East Money gives you price but not intra-day NAV estimate. Tiantian gives you NAV estimate but not L2 price. So you have to join them on the fund code. Cross-check also catches the case where one API starts returning stale data, which happens more than you'd think.

Storage

Single SQLite file, one row per (code, timestamp). Append-only. ~300 funds × 26 snapshots/day × 365 days = ~3M rows/year. SQLite eats that for breakfast.

I briefly tried Postgres. Moved back to SQLite after two weeks because the entire deploy is a file copy and backups are cp lof.db lof.db.bak.

Frontend

Next.js 15, ISR with revalidate: 900. The page is essentially a table sorted by absolute premium, with a tiny sparkline of the last 48 hours per fund.

The sparkline was the part I over-engineered. First I pulled in a charting library (120KB), then I swapped it for a 40-line inline SVG component. Same visual, 3% of the bundle size.

Three things I got wrong on the first try

1. I trusted the "premium" column on 东财

The portal shows a premium column. It's computed off yesterday's official NAV, not the intra-day estimate. For a QDII holding US stocks that rallied 2% overnight, "yesterday's NAV" understates the fund by 2% before the market even opens, so the premium column is systematically inflated on up days and depressed on down days.

Using the estimated NAV instead (the one Tiantian publishes intra-day) cut the noise dramatically. The high-premium list used to be "whatever went up last night in the US." Now it's actually unusual positioning.

2. I assumed 15-minute cadence was fine

It mostly is. But around 09:30 and 14:57 (CN market open / close auction) the price moves 0.5–2% in a single minute. A 15-minute snapshot misses those.

Compromise: 15-min during the day, 1-min windows around open/close auctions. cron with two schedules.

3. I forgot time zones, twice

Tiantian returns Beijing time with no tz marker.
East Money returns Unix timestamps in ms.
My server runs UTC.
My browser renders in Sydney time.

First bug: charts were off by 8 hours. Second bug: I "fixed" it by hard-coding +8, then flew to Sydney, and everything shifted again.

Final rule: store UTC in SQLite, tag Beijing explicitly at the API boundary, format to the browser's locale in the client. Boring, but it's the only approach that survives moving.

Does the data actually give you alpha?

Honestly — mostly no. Here's what a month of logs looks like in practice:

80% of the top-premium funds on any given day are just "US market gapped up overnight, retail is buying the reopen." By the time you see it, the arb is gone.
15% are chronic premium funds — usually QDII with exhausted quota. You can't subscribe at NAV even if you wanted to. The premium is a structural access-fee, not mispricing.
Maybe 5% are genuinely odd: a small-cap sector LOF that jumped on news nobody else was tracking, or a fund where the manager announced something that moved NAV estimate but not price yet.

That 5% is the reason the dashboard exists. Not as a trading signal on its own, but as a "huh, why is this one weird?" attention filter.

What I'd do differently if I rebuilt it today

Push notifications instead of pull. I still refresh the page. A Telegram bot that pings me when premium > 2σ would be 10x more useful.
Historical NAV backfill. My DB starts from the day I deployed. If I'd backfilled 2 years from Tiantian's archive, regime comparisons ("is this premium unusual for this fund?") would actually work.
Skip the live sparkline. Nobody looks at it. A single "premium now vs 7-day avg" number would convey more.

Summary for the impatient

LOF premium = on-exchange price minus intra-day estimated NAV. Don't use the portal's published premium column; it's anchored on T-1 NAV.
Two APIs, join on fund code, cross-check. SQLite is enough. 15-min cadence + 1-min around auctions.
Most "premiums" are just timezone artifacts or quota constraints. The signal you want is the ~5% of funds that are genuinely priced weird today.
Store UTC, tag at the boundary, format at render. Every time.

If you end up building something similar and hit a case I didn't cover — especially around holiday calendars for A-shares vs HK vs US simultaneously — I'd love to compare notes in the comments.

Karpathy's LLM Knowledge Base SEO: I applied the pattern for 12 months and here's what I learned

Jim L — Mon, 13 Apr 2026 02:48:41 +0000

Karpathy's LLM Knowledge Base × SEO: I applied the pattern for 12 months and here's what I learned

On April 3, 2026, Andrej Karpathy posted a short but influential note about using LLMs to build personal knowledge bases. The premise: instead of RAG pipelines and vector databases, you manually clip raw sources into a raw/ folder, let an LLM distill them into structured wiki pages, and query the graph later with your LLM CLI of choice.

No SaaS lock-in. No embeddings. No subscription. Just markdown and an LLM that knows the schema.

I'd been drowning in scattered SEO research for a year — running openaitoolshub.org, an AI tools directory that's gone from DR 0 to DR 30 in 12 months, 126 articles, 130+ earned backlinks. My notes were spread across Notion, Kagi Assistant, local markdown files, a neglected Readwise Reader queue, and a thousand unread tabs. Karpathy's pattern gave me the discipline to consolidate everything into a single Obsidian vault that an LLM could maintain.

This article walks through what I built, the key design decisions, and the one contradiction-preservation trick that changed how I think about personal knowledge bases entirely.

The five-step pattern

Karpathy's original framing was simple:

Set up raw/ — every source you encounter, unedited
Set up wiki/ — structured concept pages the LLM maintains
Distill with an LLM — run a pass where Claude/Codex/etc reads raw sources and updates wiki pages
Cross-link with [[wikilinks]] — let the LLM suggest relationships between concepts
Query the graph with your CLI — ask questions months later, get synthesized answers from the vault

The genius is in step 3 — the LLM does the hard work of synthesis, contradiction detection, and cross-referencing. You do the reading and judgment calls.

How I adapted it for SEO

SEO is a moving target. What worked in Q4 2024 is wrong by Q2 2025. Google's March 2026 Core Update just rewrote half the playbook. I needed a system that could absorb new evidence and propagate updates without me manually re-reading every page.

My vault structure:

seo-obsidian/
├── Home.md                    # glassmorphism dashboard
├── CLAUDE.md                  # LLM operations guide
├── wiki/
│   ├── schema.md              # the concept-page template rulebook
│   ├── concepts/              # 12 SEO concept pages
│   ├── tools/                 # 3 tool profiles
│   ├── people/                # 1 person profile (Karpathy)
│   └── indexes/               # alphabetical catalogs
├── raw/
│   ├── README.md              # explains the three-layer architecture
│   ├── articles/              # long-form sources
│   └── practitioner-notes/    # curated short-form observations
└── maps/
    └── SEO-Domain-Map.canvas  # 21-node mind map

Every concept page follows a strict schema: ## TLDR, ## Key Points, ## Details, ## Applied Example, ## Related Concepts, ## Sources. The rigidity felt annoying at first, but it pays off at query time because Claude knows exactly where to look for each piece.

Three design decisions worth discussing

1. Preserve contradictions instead of resolving them

On April 10, Zhang Kai published a 602-prompt study claiming structured content (H2/bullets/tables) correlates with AI citation. On April 11, a Japanese SEO practitioner published experiments claiming structured data does NOT help AI understanding.

In a traditional wiki I'd have to pick one. In the Karpathy pattern, both claims live in the vault. The Zhang Kai finding is in the main section of geo-generative-engine-optimization.md. The Suzuki counter-evidence is in a ⚠️ Counter-Evidence callout right below it. When I query the vault with Claude, I get both cited.

This is the single most important insight I took from applying the pattern: honest knowledge > confident answers. The vault is a snapshot of the field's current state of confusion, not an attempt to pretend the confusion doesn't exist.

2. The ripple effect as the compounding mechanism

When I add a new raw source, I don't manually update related concept pages. I tell Claude:

$ claude
> Ingest raw/practitioner-notes/zhang-kai-602-prompt-geo-study.md 
> following wiki/schema.md. Update all related concepts with the new 
> evidence and flag any contradictions.

Claude then:

Reads the new source
Decides which of the 12 existing concept pages it affects
Updates each one with the new evidence
Flags contradictions against existing claims
Updates the concept index
Writes a log entry

One source → 5-15 pages updated → all in 45 seconds.

This is what makes it compound. Most note-taking systems are linear (you add, you rarely re-read). This one is multiplicative — every new source makes the whole wiki incrementally smarter.

3. Strict concept-page schema > flexible notes

I experimented with both. Flexible concept pages were easier to write but hell to query. Strict ones were slightly annoying to fill out but let Claude parse them reliably.

The schema:

aliases: []
tags: []
sources: []
cssclasses: [seo-brain-concept]

# Concept Title

## TLDR
One paragraph, 200-250 words. This is what AI engines cite.

## Key Points
5-8 bullet points.

## Details
The main content, 800-1500 words. Can have sub-sections.

## Applied Example
A concrete worked scenario.

## Related Concepts
- [[concept-a]] — why it's related
- [[concept-b]] — why it's related

## Sources
- External URLs
- raw/... paths

Every single concept page follows this. It's like a database schema — restrictive, but queryable.

Three concrete SEO insights that came out of the exercise

Insight 1 — Mean AI-cited content length is 1,375 characters

Zhang Kai's study measured the length of every fragment cited by ChatGPT, Perplexity, and Google AI Overview across 602 prompts. The mean was 1,375 characters — roughly 200-250 words, or about 10 sentences.

Practical implication: write TL;DR blocks of 200-250 words near the top of every article. Break the body into H2-bounded sections of 1,000-1,500 characters. That's the GEO sweet spot for citation.

Insight 2 — Google's March 2026 Core Update targets 7 specific AI writing patterns

Kill these and your content survives:

"Not just X, but Y" constructions
Em-dash overuse
Triad lists ("powerful, elegant, and fast")
Formulaic openers ("In today's fast-paced world...")
Breathless enthusiasm ("game-changing")
False-authority hedging ("It's worth noting that...")
Broad-to-narrow openings

I went through every article on openaitoolshub.org and stripped these patterns. Traffic stabilized. Articles that failed the update all shared these tells.

Insight 3 — Free dofollow directories above DR 55 exist

Conventional wisdom says free directories are DR 0-10 and useless. Actual: I found at least 12 free dofollow directories above DR 55. A field study in early April showed that adding 50 such backlinks moved a DR 46 site to DR 50 in one week.

The misconception comes from the early 2010s when directory submission was spammed to death. Post-2024, curated directories (Navs Site, Acid Tools, Ben's Bites, ShowMySites, NextGen Tools) are legitimate editorial sources.

What tools I used (and didn't use)

Used:

Obsidian (free) for the vault UI
Claude Code for the distillation + query layer
Ahrefs (~$99/month, but sem.3ue.com mirror for specific lookups)
Google Search Console (free) — the most important SEO tool for indie devs

Explicitly NOT used:

No SEO course (they go stale)
No paid link-building service (PBNs are a DMCA landmine)
No vector database (the whole point of the Karpathy pattern is avoiding this)
No subscription SaaS tools beyond Ahrefs

The goal was to keep the tool budget under $100/month and replace expensive tools with LLM-assisted workflows. Mostly worked.

What's next

I packaged the vault as "SEO Brain" for other indie devs. Free 5-concept starter kit is at openaitoolshub.org/en/seo-brain (canonical source, no Medium paywall). Full 12-concept Starter Edition is on Gumroad, $19 launch week, $29 regular.

More importantly — if you're doing personal research in any domain, I think Karpathy's LLM KB pattern is the right structure for 2026. Try it with your own domain (investing research, game dev, climate science, whatever) and let me know what you learn.

The compounding is real. The contradictions-preserved discipline is the trick.

About the author

Jim runs openaitoolshub.org (DR 30, 126 articles, solo) and four sister sites covering trading, SaaS, AI tools, and game directories. He writes about applying indie dev patterns to SEO at his main site.

This article's canonical version lives at openaitoolshub.org/en/seo-brain. Dev.to is a syndication copy.

I Tried Microsoft Agent Framework 1.0 — Three Days In, Here Is What I Think

Jim L — Fri, 10 Apr 2026 03:39:54 +0000

The Merge Nobody Asked For But Everyone Needed

Microsoft released Agent Framework 1.0 on April 7. The pitch: one SDK that fuses Semantic Kernel (enterprise middleware, telemetry, type safety) with AutoGen (multi-agent chat orchestration). No more stitching two libraries together with duct tape.

I spent three days testing it on real work instead of toy examples. Here is what I found.

What Actually Works

The graph-based workflow engine is the star. You define agent relationships as a directed graph — orchestrator hands off to researcher, researcher passes to coder, coder sends to reviewer. Each agent keeps its own session state.

I built a four-agent pipeline that parsed GitHub issues, drafted code, ran tests, and generated PR descriptions. Total setup: around 120 lines of Python. The DevUI debugger runs locally and shows real-time message flows between agents. I caught two infinite-loop bugs through it that would have burned through my API budget otherwise.

MCP support landed on day one. My agents could call external tools through the Model Context Protocol without custom wrappers. I connected a filesystem server and a web search tool in maybe 15 minutes.

Where It Falls Short

Python support feels rushed. The .NET SDK is polished — types, middleware hooks, proper async. The Python package works but documentation has gaps, and some features like the evaluation framework are .NET-only for now. If you are a Python shop, expect to read source code more than docs.

A2A (Agent-to-Agent protocol) is version 1.0 but the ecosystem is basically Microsoft talking to Microsoft right now. Cross-framework interop with LangChain or CrewAI agents is not there yet. Give it six months.

Boilerplate is real. Setting up a simple two-agent chat requires more ceremony than LangGraph or Claude Agent SDK. Fine for enterprise teams with dedicated infra — overkill for a weekend prototype.

How It Stacks Up

I wrote a full breakdown comparing Microsoft Agent Framework against Claude Agent SDK, LangGraph, and CrewAI on my site with actual code examples and benchmark numbers.

Short version: Agent Framework wins on enterprise features, Claude SDK wins on simplicity, LangGraph wins on flexibility. Pick based on where you are running production workloads.

Who Should Care

If your company already runs on Azure and uses Semantic Kernel, this is the obvious next step. The migration path from SK plugins to Agent Framework tools is nearly 1:1.

If you are an indie developer testing the waters, I would start with Claude Agent SDK or LangGraph first. Lower friction, faster prototyping. Come back to Microsoft Agent Framework when you need enterprise observability or graph-based multi-agent workflows.

My Setup

I tested on Python 3.12, WSL2 Ubuntu, with GPT-4.1 and Claude Opus as backend models. Cost for three days of experimentation: roughly $14 in API calls. The DevUI runs locally on port 5000 and uses about 200MB of RAM.

One thing I appreciated: the framework does not force you into Azure. You can use any OpenAI-compatible endpoint, local models through Ollama, or Anthropic directly. The Azure AI Foundry integration is optional, not required.

Bottom Line

Microsoft Agent Framework fills a gap that has existed since enterprises started asking "how do I put AutoGen in production?" The answer: merge it with your enterprise middleware, add proper observability, ship it.

Not revolutionary. But solid engineering that solves a real problem for a specific audience. Which is probably the more valuable outcome anyway.

Google Just Showed Us What Happens When You Throw Out the Token-by-Token Playbook

Jim L — Thu, 09 Apr 2026 03:35:06 +0000

Every LLM you have used works the same way. It predicts the next token, then the next, then the next. One at a time. Autoregressive generation. That is how GPT-4o works, how Claude works, how Gemini 2.5 Pro works.

Google just said: what if we stop doing that?

Gemini Diffusion generates text the way image models generate images. Instead of building a sentence left to right, it starts with noise and refines the entire output simultaneously. The claimed speedup is 5x over comparable autoregressive models.

I have been thinking about what this actually means for the way I build things.

The speed problem nobody talks about

When you are making a single API call, the difference between 2 seconds and 0.4 seconds does not matter much. But when you are running batch jobs — processing 500 documents, generating test cases for an entire codebase, summarizing a week of customer support tickets — that 5x adds up fast.

I run a lot of batch processing through Claude and GPT-4o. A typical overnight job hits the API maybe 2,000 times. At current speeds that takes roughly 3 hours. If diffusion models actually deliver on the 5x claim, that same job finishes in 36 minutes. That changes whether I can run it during lunch instead of overnight.

Why I am skeptical

The 5x number comes from controlled benchmarks. Real-world performance depends on context length, output complexity, and how the model handles edge cases. I have seen plenty of impressive benchmark numbers that fall apart when you throw messy real data at them.

Also, diffusion models for text are genuinely new territory. Image diffusion had years of iteration before it got reliable. Text diffusion is maybe six months into serious research. The failure modes are different — you can get away with a slightly wrong pixel in an image, but a slightly wrong word in code breaks everything.

What I am actually going to do

Nothing yet. I am not rewriting any pipelines around a model that is still in research preview. But I am watching two things mainly: whether the speed holds on long outputs (2000+ tokens), and whether Google actually ships a usable API at a reasonable price. The code quality question is secondary if the pricing is wrong.

If all three check out, I will probably move my batch processing over first and keep interactive coding on Claude. Speed matters less when you are pair programming. It matters a lot when you are processing data at scale.

What got my attention is not this specific model. Someone proved the approach works at all. If Google can do it, Anthropic and OpenAI are probably working on their own versions. In a year we might look back at autoregressive-only models the way we look back at RNNs — technically functional but obviously not the final answer.

Or the whole thing might hit a wall at 1000 tokens and we are back to business as usual. Could go either way.

I Replaced Claude with Gemma 4 for a Weekend — Here's What Broke

Jim L — Wed, 08 Apr 2026 05:05:55 +0000

I run five websites from Sydney and use AI models daily — for blog drafts, code fixes, SEO analysis, quick research. Most of my workflow runs on Claude Sonnet because it's consistent and doesn't need babysitting. So when Google dropped Gemma 4 on April 2, 2026 under Apache 2.0, I figured I'd stress-test it over a weekend before forming any opinions.

Short version: it's genuinely impressive in places, mildly annoying in others, and the license alone changes a lot of the math.

What Gemma 4 Actually Is

Gemma 4 is Google's latest open-weight model family. Released April 2, 2026. Apache 2.0 license, which means you can use it commercially, modify it, redistribute it — no royalties, no restrictions on derivative works. That's meaningful.

The family ships in several sizes: 4B, 12B, 27B, and a new 96B variant. The 27B is the one most people will actually run locally (needs roughly 20GB VRAM in full precision, or 12GB quantized to Q4).

It's multimodal — image understanding built in, not bolted on. And there's genuine agentic scaffolding baked into the instruction-tuned variants, meaning it handles multi-step tool use more coherently than Gemma 3 did.

What I Actually Tested

Test 1: Code generation for a Next.js component

I gave it a prompt I regularly use with Claude: build me a React component that fetches data from a Supabase table, handles loading/error states, and renders a responsive table.

Gemma 4 27B (via Ollama, quantized) produced working code on the second attempt. First attempt had a minor type error in TypeScript. Second attempt fixed it without me explaining what was wrong.

Claude Sonnet would have nailed this on the first try. But Claude costs money per token. Gemma 4 running locally costs electricity.

Test 2: Document analysis (multimodal)

I threw a screenshot of a GA4 analytics dashboard at it and asked it to summarize traffic trends. Gemma 4 read the numbers correctly but its interpretation was generic. It told me sessions were down 14% without offering any hypothesis about why. Claude tends to make inferences. Gemma 4 reports rather than reasons.

Test 3: SEO content editing

I fed it a 1,200-word blog post and asked it to identify thin sections. This went better than expected. It flagged two genuinely weak paragraphs, suggested adding a comparison table, and offered three alternative headline options that were actually good.

The Surprise (Good and Bad)

Good surprise: The 12B model is more capable than it has any right to be. I ran it on a machine with 8GB VRAM and it handled most single-turn tasks at a quality level I'd compare to GPT-3.5 era.

Bad surprise: Agentic tasks with multi-step tool use hit context length issues faster than expected. Around step four of a five-step workflow, it started losing track of earlier context.

Also: it's verbose by default. Ask it a yes/no question with nuance, it writes three paragraphs.

How It Compares

	Gemma 4 27B	Claude Sonnet 4.5	GPT-4o
Cost	Free (local) or ~$0.10/M via API	~$3/$15 per M tokens	~$2.5/$10 per M tokens
Context	128K	200K	128K
Code quality	Good, 2nd attempt	Excellent, 1st attempt	Very good
License	Apache 2.0 (fully open)	Proprietary	Proprietary

The license column is doing more work than it looks. If you need AI costs that don't scale with usage, or on-prem deployment for compliance, Gemma 4 is now a serious option.

Who Should Use This

Worth it if: self-hosting, compliance requirements, fine-tuning experiments, or budget-conscious.

Stick with Claude/GPT if: you need top-tier multi-step reasoning, heavy document inference, or don't want to manage infrastructure.

I'm not switching my main workflow off Claude. But I've moved quick classification tasks and a couple of internal scripts to a local Gemma 4 12B instance. That's probably $30-40/month in API calls I won't be making.

Not a revolution, but a genuine shift in what's viable to run without a credit card.

I Built 6 Free SEO Tools in One Day — Here's What I Learned

Jim L — Mon, 06 Apr 2026 01:38:48 +0000

SEO tools are everywhere, but most are locked behind signups, API limits, or subscription walls. I wanted something I could actually use without friction — so I built 6 tools over a weekend and open-sourced the approach.

The Tools

All run in-browser (4 client-side) or via lightweight server fetch (2 API routes). Zero external API costs.

1. Schema Markup Generator

Visual form → valid JSON-LD for FAQPage, Article, HowTo, Product, Organization, BreadcrumbList. Click "Copy HTML" and paste into your <head>. One-click link to Google Rich Results Test.

Why I built it: I was manually typing JSON-LD for every blog post. Now it takes 30 seconds.

2. LLMs.txt Generator

Input any URL, get llms.txt + llms-full.txt following the llmstxt.org standard. Fetches your sitemap, extracts titles/descriptions, formats everything.

Why it matters: AI assistants like ChatGPT and Claude check this file when users reference your site. No llms.txt = missed citations.

3. Hreflang Tag Generator

Add language/URL pairs, get self-referential hreflang HTML with x-default. Validates duplicates and missing tags.

Tiny tool, but saves me 10 minutes every time I add a new language to a site.

4. Meta Title & Description Analyzer

Pixel-accurate truncation check (Google measures in pixels, not characters). Live SERP preview, keyword density analysis, power word detection. Also flags "Best"/"Top" in titles per Google's Feb 2026 Core Update rules.

5. Robots.txt Tester

Paste your robots.txt, test any URL path against 15+ user agents — including GPTBot, ClaudeBot, PerplexityBot, and Google-Extended. Shows exactly which rule matched and whether it's Allow or Disallow.

Built this because blocking AI crawlers is becoming the default, but most people have no idea if their rules actually work.

6. OG Image Preview

Fetch any URL and see how it renders on Twitter, LinkedIn, Slack, and Discord. Each platform crops differently — this shows all four at once plus detects missing/broken tags.

Technical Decisions

Client-side first: 4 of 6 tools run entirely in the browser. No server, no API, no data retention.
Server fetch only when needed: LLMs.txt and OG Preview need to fetch external URLs (CORS), so they use Next.js API routes.
Zero API cost: No OpenAI, no paid APIs. Just fetch() + regex parsing.
Dynamic routing: One [tool]/page.tsx handles stubs for unreleased tools; specific routes override when ready.

What I'd Do Differently

Schema Generator could use client-side validation against Schema.org spec (currently just generates, doesn't validate fields). Meta Analyzer's pixel width estimation is approximate — a Canvas-based measurement would be more accurate.

Try Them

All 6 tools are live at openaitoolshub.org/seo-tools. No signup, no API key. Feedback welcome.

What free SEO tools do you actually use daily? Curious what's missing from the landscape.

I Tested Cursor 3 Glass for a Week — The Agent-First IDE Is Real, But Not for Everyone

Jim L — Sun, 05 Apr 2026 00:07:33 +0000

Cursor dropped version 3 on April 2 with a codename — Glass — and a rebuilt interface that moves the code editor into the passenger seat.

The pitch: you describe tasks in natural language, AI agents write the code, and you orchestrate. It sounds like marketing copy until you actually open the Agents Window and see three parallel tasks running across different repos simultaneously.

What Actually Changed

The old Cursor was a VS Code fork with an AI sidebar. Version 3 is something else entirely. The Agents Window is a separate workspace where each task gets its own context, its own file access, and its own execution thread. You can run local agents or cloud agents — the cloud ones persist even when you close your laptop.

Design Mode is the other big addition. You can point at a UI element and describe what you want changed. It generates the code, previews the result, and you approve or reject. For React and Next.js projects, this worked surprisingly well in my testing. For anything with complex state management, it struggled.

The Good Parts

Parallel execution is genuine. I ran a test where Agent 1 was refactoring a data layer while Agent 2 was building a new API endpoint. They didn't conflict. The context isolation means each agent sees a consistent snapshot of the codebase, and Cursor handles merging the changes.

Multi-repo support. You can open multiple repositories in a single workspace and run agents across them. For monorepo-heavy teams, this matters.

The prompt box as primary interface. Instead of navigating menus and panels, you describe what you want. "Add error handling to all API routes in /src/api" — and an agent spins up, creates a plan, and starts executing. This felt natural after about 20 minutes.

The Honest Problems

Context window limits hit fast. Large codebases — anything over roughly 50K lines — caused agents to lose track of earlier instructions. I had to break tasks into smaller chunks manually, which somewhat defeats the purpose.

Cloud agents are slow. Local agents respond in seconds. Cloud agents take 30-90 seconds to start, and they run on Cursor's infrastructure. If their servers are loaded (which happened twice during my week of testing), everything stalls.

Price jumped. Pro is still $20/month, but the Business tier at $40/month is where you get unlimited cloud agent hours. The free tier is now almost unusable for real work — you get 5 agent sessions per day.

It is no longer a code editor. If you want fine-grained control over your code, Cursor 3 fights you. The interface prioritizes agent delegation over manual editing. Some developers will hate this.

Who Should Care

If you manage a team shipping features on tight timelines, Cursor 3's parallel agents could save real hours. If you are a solo developer who enjoys writing code, this might feel like a solution to a problem you don't have.

The $2 billion ARR number tells you Cursor found its market. Whether that market includes you depends on how much of your coding you are willing to hand off to agents that are good — but not perfect.

I test AI coding tools as part of my workflow. Previously covered Claude Code, Windsurf, and OpenCode. All opinions are from actual project use, not benchmark screenshots.

For my full review of Cursor 3 Glass and how it compares to other AI coding tools, see this detailed comparison.

My 3-Month Startup Directory Submission Journey — What Actually Moved the Needle

Jim L — Fri, 03 Apr 2026 23:10:02 +0000

Over the last few months I submitted five websites to every free startup directory I could find. Not as a theoretical exercise — I needed backlinks. My domain rating was stuck at 20 and organic traffic was flat.

Here is what actually happened.

Month 1: The Naive Phase

I found a few GitHub repos listing 300+ directories and started submitting to everything. No filtering, no strategy. Just fill form, click submit, next.

Success rate: roughly 40%.

The other 60% was a mix of dead sites (404, parked domains, expired Bubble.io plans), paid-only directories pretending to be free, and forms that silently failed. I spent about 15 hours that first month and submitted to maybe 80 directories. Of those, about 30 actually listed my sites.

The worst time wasters were directories running on Bubble.io with expired plans. They look legit until you hit submit and get a deployment error. I counted 12 of these in one week.

Month 2: Getting Strategic

I started sorting directories by Ahrefs DR before submitting. Anything below DR 20 went to the bottom of the list. DR 50+ got done first.

Three discoveries changed my approach:

Blog comments work. I found a WordPress blog with DR 63 that gives dofollow links through the URL field in blog comments. One genuine comment with my website URL in the website field. No review process, no waiting. This single discovery was worth more than 20 low-DR directory submissions combined.

I eventually compiled the full list of verified directories into a startup directory submission guide with DR ratings and submission notes for each one.

Profile backlinks are underrated. Crunchbase (DR 91), Disqus (DR 91), StackShare (DR 89) — creating a profile on each of these takes under 10 minutes and gives you a link from a domain most people would pay good money for. Nobody talks about this because it is not exciting. But it works.

Badge exchange is worth it. Some directories like twelve.tools (DR 80) and wired.business (DR 73) require you to put a small badge in your site footer. In exchange you get a dofollow link from a high-DR domain. The math works out heavily in your favor.

Month 3: The Numbers

After three months of systematic directory work across five websites:

Domain rating: 20 to 29 (Ahrefs)
Referring domains: 15 to 72
Directories submitted: 200+
Actually listed: roughly 110
Dead or fake: 60+
Paid-only (despite claiming free): 30+
Dofollow confirmed: about 70

The directories that consistently showed up fastest in Ahrefs backlink reports: SaaSHub, ExactSeek, sitelike.org, twelve.tools, and Crunchbase profiles. Most others took 2-4 weeks to get crawled.

What I Would Tell Someone Starting Today

Start with DR 50+ directories. The ROI on low-DR directories is almost zero for SEO purposes.

Batch your submissions to 5-10 per day. Some directories share IP tracking and will flag rapid submissions.

Keep a spreadsheet. Track: directory name, DR, submit URL, whether you need to log in, CAPTCHA type, and submission date. You will forget what you already submitted otherwise.

Do not pay for directory submissions. Every directory worth submitting to has a free tier. The paid-only directories at $29-149 per listing are not worth it when free alternatives with similar or higher DR exist.

My Shortlist: Start With These 10

If I had to pick just 10 directories to submit to first:

Crunchbase (DR 91) — profile with website link
twelve.tools (DR 80) — badge exchange, dofollow
ExactSeek (DR 73) — simple form, dofollow, 1/day limit
wired.business (DR 73) — badge exchange, dofollow
sitelike.org (DR 71) — text CAPTCHA, dofollow
Future Tools (DR 69) — AI tools focus
SaaSHub (DR 55) — URL-only form, auto-detect
SubmissionWebDirectory (DR 61) — image CAPTCHA
Startup Inspire (DR 48) — multi-category
Mamavation (DR 63) — blog comment, instant dofollow

I documented over 200 directories with DR scores, submit URLs, link types, and specific notes about CAPTCHAs and gotchas. That resource covers everything in detail if you want to go deeper.

The honest truth is that directory submissions alone will not get you to DR 50. But they are the foundation. Combined with profile backlinks, blog comment links, and content that naturally attracts links, the compound effect adds up faster than most people expect.