DEV Community: Bruce Lee

I built an AI tools directory in 2026. Here's the SEO playbook (the honest version)

Bruce Lee — Fri, 04 Sep 2026 15:29:47 +0000

There are hundreds of AI tools directories at this point. So the obvious question is why I built another one. Short answer: I run AI products myself, I kept looking for where to launch them, and I noticed most directories are either scraped garbage or empty link farms. That gap is the product. showmebest.ai is my attempt at a curated one, and this post is the full breakdown of how it's built for search, not just how it looks.

This is not a "I made $8k last month" post. The site is young and pre-revenue. What it does have is a working SEO setup and an early traffic pattern that I think is more useful than another income screenshot.

1. The niche reality: you will not rank for "best AI tools"

Let's kill the fantasy first. The head term "best AI tools" is owned by sites with a decade of domain authority. A new directory competing there is donating its time.

What a new directory can win, in order of difficulty:

"Submit AI tool" and its variants — this is the sleeper keyword of the whole niche. Every indie hacker who ships a product searches exactly this. It's low volume, high intent, and the SERP is weak.
Long-tail discovery terms — "AI tools for tattoo artists", "AI tools to turn photos into line art", "best free noise reduction AI". Each is small. There are hundreds.
Branded and alternative searches — "toolname review", "toolname alternatives". Programmatic pages cover this automatically.

So the entire site architecture is designed bottom-up around #2 and #3, with the submission page optimized for #1. The homepage barely matters for search. That was a deliberate, slightly painful decision.

2. One page per tool is the whole game

Every listed tool gets a real page: screenshots, a description that is actually written (not the tool's own homepage copy pasted in), category tags, pricing summary, and the outbound link. That page is the SEO unit.

// app/tools/[slug]/page.tsx
export async function generateStaticParams() {
  const tools = await getAllTools();
  return tools.map((t) => ({ slug: t.slug }));
}

export async function generateMetadata({ params }) {
  const tool = await getTool(params.slug);
  return {
    title: `${tool.name} Review, Pricing & Alternatives (2026)`,
    description: `${tool.name} in plain words: what it does, who it's for,
      what it costs, and ${tool.alternativesCount} alternatives.`,
    alternates: { canonical: `https://showmebest.ai/tools/${tool.slug}` },
  };
}

The title pattern matters more than it looks. "Review, Pricing & Alternatives" stacks three search intents onto one page, and those are queries the tool's own site can never satisfy, because nobody writes honest alternatives of themselves. That's the structural advantage a directory has over every tool's marketing site. Use it.

3. Structured data, because directories are exactly what it's for

Schema markup is boring until you realize a tools directory is literally a database of SoftwareApplication entities. Google has a vocabulary for precisely this. Not using it is leaving free SERP real estate on the table:

{
  "@context": "https://schema.org",
  "@type": "SoftwareApplication",
  "name": "Tool name",
  "applicationCategory": "DesignApplication",
  "description": "One honest sentence about what it does",
  "offers": { "@type": "Offer", "price": "9.99", "priceCurrency": "USD" },
  "aggregateRating": { "@type": "AggregateRating", "ratingValue": "4.6", "ratingCount": "23" }
}

Plus the unglamorous checklist that moves the needle for a page-heavy site:

Sitemap split by type (tools / categories / static) so indexation is observable per section in Search Console. When a section stalls, you know where to look.
Category pages as real content, not empty grids. Each category page gets a written intro answering "which AI tools belong here and why", then the tool grid. An empty grid page is thin content with extra steps.
Internal links with descriptive anchors from related tools ("alternatives") and from categories to tools. The links are the directory's content graph.

4. The curation bar is the moat

Here's the uncomfortable truth about the niche: most directories will index anything with an AI logo, because volume feels like growth. In 2026 that's exactly what Google's spam systems are tuned to catch, and sites full of auto-generated tool pages are getting deindexed weekly.

So the rule on showmebest is: every listing gets its own screenshots, a description I write from actually poking at the tool, and pricing pulled from the tool's real pricing page. It's slower. That's the point. The moat against the other 500 directories isn't more tools, it's pages that are worth a visit.

5. The growth loop that actually works for directories

Directories have a cheat code that normal SaaS products don't: your users are founders who also want traffic. That makes the loop:

Founder searches "submit AI tool", finds the site, submits theirs (free).
I review and list it, notify them, they share the listing → social traffic + a backlink to the directory.
Their listing ranks for "toolname review / alternatives" within weeks → real search users arrive.
Those users find other tools → founders of those tools notice the referral traffic in their analytics → they come submit too.

Metric	Now
Tools listed	[X]
Organic clicks / mo	[X]
Top long-tail query	[X]
Founder submissions via "submit" page	[X]

One example from the other side of the loop: my own product AI Line Art was one of the first tools listed, and watching which listing pages actually pulled search traffic versus which flopped is where most of the playbook above came from. Running both sides, the directory and the product, is the fastest SEO education I've had.

6. Monetization, honestly

The site is pre-revenue and I'm saying that on purpose. The obvious path is featured placements for founders who want the visibility, and the listing traffic pattern above is the pitch: you're not buying a link, you're buying a page that ranks for your product name's review and alternative searches.

But I'm not going to write a monetization section with invented numbers. When there's real data, it goes in a follow-up post.

Lessons so far

Win the bottom of the SERP first. Long-tail and branded queries are where a young directory gets its first few hundred monthly visitors. Head terms are a year-long project, not a launch goal.
"Submit your AI tool" is the best keyword in the niche. It converts founders, who create content for you, who attract searchers, who attract founders.
Curation is compounding, volume is a liability. Unique descriptions and real screenshots are slow today and safe next year.
Directories are schema markup made flesh. If your site is a database of things, use the vocabulary Google already built for it.

If you're building an AI tool and want a listing (free, reviewed by a human), the submission page is at showmebest.ai. And if you're building a directory yourself, I'm happy to answer questions in the comments about the page structure or the submission loop. 👇

How I built an AI Line Art SaaS with Next.js, a worker queue, and Stripe credits

Bruce Lee — Fri, 04 Sep 2026 15:06:53 +0000

Hey! 👋 I recently shipped ailineart.com, an AI line art generator that turns photos and text prompts into clean line art (sketch, pencil, woodcut, watercolor styles). It's a solo-built, bootstrapped SaaS with a free tier and paid subscriptions.

Plenty of posts cover "I picked Next.js and it was great." I want to cover the three things that actually decided whether this product would work or fall over:

Running long AI jobs without blocking web requests
Credit accounting that can't be cheated or double-charged
Stripe webhooks that survive retries and outages

If you're building any AI SaaS where a generation takes 10–60 seconds and users pay per generation, this is the plumbing you'll need. Let's go. 🚀

The Stack at a Glance

Layer	Choice	Why
Frontend + API	Next.js (App Router)	SSR for SEO (this is a tool site — search traffic is the business), one repo, one deploy
Background jobs	Dedicated worker process + PostgreSQL queue	AI calls take tens of seconds; they must never live inside a request
Database	PostgreSQL	Jobs, users, credit ledger — one source of truth
Payments	Stripe (subscriptions + one-off credits)	Webhook-driven, idempotent credit grants
AI generation	Third-party image-generation API	Pay per generation instead of paying for idle GPUs

No GPUs, no Kubernetes, no microservices. One web container, one worker container, one database. That's the whole diagram — and it's deliberate.

Part 1: Never Generate Inside a Request

The naive implementation everyone starts with:

// ❌ What I did NOT do
app.post("/api/generate", async (req, res) => {
  const image = await callImageAPI(req.body.prompt); // 30-60s!
  res.json({ image });
});

This dies three ways: serverless function timeouts, mobile browsers killing idle connections, and users retrying when the spinner "looks stuck" — which silently double-bills your AI provider.

The architecture I landed on:

┌─────────┐     1. POST /api/jobs      ┌────────────┐
│ Browser │ ─────────────────────────▶ │ Next.js API │ ──▶ INSERT job (queued)
└─────────┘ ◀───────────────────────── └────────────┘      deduct credits (ledger)
             2. { jobId } immediately
                                                        ┌────────┐
                    3. worker polls + claims job        │ Worker │ ──▶ call AI API
             ┌────────────────────────────────────┐     └────────┘      upload result
             │  SELECT ... FOR UPDATE SKIP LOCKED │           │
             └────────────────────────────────────┘           ▼
┌─────────┐     5. GET /api/jobs/:id                  job → succeeded / failed
│ Browser │ ─────────────────────────▶ 4. write result to DB (+ refund credits if failed)
└─────────┘

The job queue is just a Postgres table — no Redis, no Celery, no extra infra to babysit:

CREATE TABLE jobs (
  id            UUID PRIMARY KEY DEFAULT gen_random_uuid(),
  user_id       UUID NOT NULL REFERENCES users(id),
  status        TEXT NOT NULL DEFAULT 'queued',  -- queued|running|succeeded|failed
  params        JSONB NOT NULL,
  result_url    TEXT,
  credits_cost  INT  NOT NULL,
  attempts      INT  NOT NULL DEFAULT 0,
  locked_at     TIMESTAMPTZ,
  created_at    TIMESTAMPTZ NOT NULL DEFAULT now()
);

The worker claims jobs atomically, so it's safe to run multiple workers later:

-- Claim one job. SKIP LOCKED means concurrent workers never grab the same row.
UPDATE jobs SET status = 'running', locked_at = now()
WHERE id = (
  SELECT id FROM jobs
  WHERE status = 'queued'
  ORDER BY created_at
  FOR UPDATE SKIP LOCKED
  LIMIT 1
)
RETURNING *;

The lesson everyone learns the hard way: if a job fails after credits were deducted, refund them. My failed transition does INSERT INTO credit_ledger (... amount = +credits_cost ...) in the same transaction as the status update. Users forgive failures; users do not forgive losing credits with no trace.

Part 2: Credits Are an Accounting Problem, Not a Counter

My first draft had users.credits INT. That breaks the moment two requests race: a batch generation and a webhook refill both fire, and suddenly users have negative credits or free generations.

The fix: an append-only ledger, and the balance is a sum.

CREATE TABLE credit_ledger (
  id         BIGSERIAL PRIMARY KEY,
  user_id    UUID NOT NULL,
  delta      INT  NOT NULL,        -- +10 grant, -1 generation, +1 refund
  reason     TEXT NOT NULL,        -- signup_bonus | subscription | generation | refund
  ref_id     TEXT UNIQUE,          -- idempotency! see Part 3
  created_at TIMESTAMPTZ NOT NULL DEFAULT now()
);

Every mutation is a row. The ref_id UNIQUE constraint is the unsung hero: it makes every credit grant idempotent. If Stripe calls the webhook twice (it will — retries are a feature, not a bug), the second insert fails on the unique constraint and the user doesn't get double credits.

Balance check before accepting a job is one query, and the deduction + job insert share one transaction, so you can never end up with a job that wasn't paid for:

await db.transaction(async (tx) => {
  const balance = await getBalance(tx, userId);
  if (balance < cost) throw new InsufficientCreditsError();

  await tx.insert(creditLedger).values({ userId, delta: -cost, reason: "generation", refId: jobId });
  await tx.insert(jobs).values({ id: jobId, userId, creditsCost: cost, params });
});

Part 3: Stripe Webhooks — Assume Every One Will Arrive Twice

Subscriptions + credits means the money side has exactly one job: when a payment succeeds, credits appear, exactly once. Everything else is negotiable.

The three webhooks that matter:

checkout.session.completed → first purchase or credit pack
invoice.paid → monthly renewal, grant the monthly credits
customer.subscription.deleted → downgrade to free tier

And the rules that saved me:

export async function POST(req: Request) {
  const sig = req.headers.get("stripe-signature")!;
  const event = stripe.webhooks.constructEvent(await req.text(), sig, WEBHOOK_SECRET);

  // Idempotency: ledger.ref_id = event.id makes replay harmless.
  // The DB unique constraint IS the dedup layer — no Redis needed.
  await grantCredits({
    userId: event.data.object.metadata.userId,
    delta: monthlyCredits,
    reason: "subscription",
    refId: event.id, // 👈 duplicate delivery → unique violation → ignored
  });

  return new Response("ok");
}

Verify signatures. An unauthenticated /webhook endpoint is an open faucet for free credits.
Grant credits only from webhooks, never from the redirect back to your site. Users close tabs; Stripe retries don't.
Persist the raw event before processing. When (not if) your handler has a bug at 2am, you can replay from your own table instead of begging Stripe support.

Part 4: What It Costs

Real numbers, since every "I built an AI SaaS" post skips them:
| Item | Monthly cost |
|---|---|
| Hosting (web + worker + Postgres) | $[FILL] |
| Image-generation API (per-generation, scales with usage) | ~$[FILL] per 1,000 generations |
| Stripe | 2.9% + $0.30 per transaction |
| Total fixed | $[FILL]/mo |

The per-generation pricing of the AI API is the whole business model in one line: free-tier users cost me $[FILL]/day, and a Basic subscription ($9.99) covers [FILL] generations of API cost. Knowing that ratio is the difference between "a fun project" and "a business."

Biggest Lessons Learned

The queue is the product. Users judge AI apps by the waiting experience: instant jobId response, a real progress state, and a page that survives refresh (because it reads state from the DB, not from memory).
Treat every external call as eventually-failing. The AI API will time out; Stripe will redeliver. Idempotency keys and refunds aren't nice-to-haves.
Postgres was enough. I was ready to add Redis, a proper job framework, and a separate auth service. None of it was needed at this scale. One database, SKIP LOCKED, and an append-only ledger got me to production.
SSR is not optional for tool sites. The majority of signups arrive from search — a client-rendered SPA would have quietly killed half the funnel.

Try It

You can see the whole thing live — upload a photo, watch the queue do its thing, get line art in seconds — at ailineart.com. Free tier includes daily credits, no card required.

Happy to answer questions in the comments about the queue design, Stripe credit grants, or running a lean AI SaaS solo. 👇

From One Line of Text to a Complete Song

Bruce Lee — Sun, 12 Jul 2026 14:24:57 +0000

Most side projects begin with a vague idea.

Music is not very different. You may know the atmosphere you want, but not the chords, melody, arrangement, or even the right words to describe it.

I wanted to see how far a single sentence could go:

An electronic pop song about driving through an empty city at 2 a.m.

There is a mood in that sentence, but not much else. No tempo, song structure, instruments, or lyrics. Traditionally, turning it into a complete track would require several separate decisions and probably a few hours inside music production software.

Instead, I used it as the starting point for a song on DeepSong.ai.

The first attempt

DeepSong offers a simple mode where a song can begin as a plain-language description. I entered the original sentence without adding any technical music terms.

The result captured the broad idea, but it also exposed everything the prompt had failed to explain.

“Electronic pop” could mean a bright dance track, a slow synth ballad, or something darker and more cinematic. An “empty city” could feel peaceful, lonely, or threatening. The first generation had to make those choices on its own.

That was useful. Hearing one interpretation made it much easier to describe the version I actually wanted.

A better prompt

For the second attempt, I rewrote the prompt:

A restrained electronic pop song about driving alone through an empty city at 2 a.m. Start with soft analog synths and a distant drum machine. Keep the verses quiet and slightly tense, then open into a wide, melodic chorus. Male vocal, medium tempo, reflective rather than sad.

This version contains several kinds of direction:

A genre: electronic pop
A setting: an empty city at night
An emotional boundary: reflective, not sad
An arrangement: quiet verses followed by a larger chorus
Instrument ideas: analog synths and a drum machine
Vocal and tempo preferences

The prompt is still readable as normal prose. It does not require a list of production parameters or knowledge of music theory.

That is one of the more practical things about generating music from language: the interface between the idea and the software is ordinary writing.

Moving into custom mode

A description is enough for exploration, but lyrics need more deliberate control.

DeepSong’s custom mode separates the title, lyrics, musical style, and other choices. I gave the track a working title, Streetlights After Two, and sketched a short structure:

[Verse]
Traffic lights change for nobody
Storefronts sleep behind the glass
Every road looks unfamiliar
Even ones I've driven past

[Chorus]
Streetlights after two
Turning red to green
The whole city disappears
Somewhere in between

Structure tags such as [Verse] and [Chorus] help communicate how the words should be arranged. They also make revision easier. If the chorus feels too crowded, it can be shortened without rewriting the entire prompt.

This is where the process started to feel less like requesting a finished asset and more like working through a draft.

Generation is most useful as a loop

The first custom version was not the final one.

One line had too many syllables. The transition into the chorus felt abrupt. The vocal delivery was stronger than the quiet mood needed.

Those were not failures so much as feedback. A written lyric can look fine on a screen and still feel awkward once it is sung.

The workflow became:

Describe the song.
Generate a version.
Listen for one specific problem.
Change the prompt or lyrics.
Generate again.

Short feedback loops matter in creative work. When producing another draft takes hours, people tend to protect weak ideas because they have already invested time in them. When a draft is quick to test, it becomes easier to discard a line, change direction, or try something strange.

Where this becomes useful

The obvious application is songwriting, but complete songs are only one part of it.

A developer building a game can test different musical directions for a scene before the soundtrack is finalized. A YouTube creator can explore background music shaped around the pace and tone of a video. A podcaster can prototype an intro. A designer can give a product demo its own temporary soundtrack.

It can also help with communication.

“Make it more cinematic” means different things to different people. Generating a quick reference track gives collaborators something concrete to discuss. They can point to the rhythm, instrumentation, or energy instead of debating adjectives.

For early prototypes, that can be more valuable than obtaining a perfect track.

Keeping track of the results

Experiments create files quickly, and filenames such as final-version-3-really-final.mp3 are not much of a system.

DeepSong keeps generated tracks in a personal song library, so versions can be replayed and managed after the initial session. Tracks can also be created privately, while public creations can be shared with the wider community.

That distinction matters. Some generations are finished pieces; others are sketches, references, or ideas that should remain part of a private creative process.

What I learned from the experiment

The main lesson was not that one sentence can magically become a perfect song.

It was that one sentence can become something you can react to.

Before hearing the first generation, “electronic pop in an empty city” seemed specific enough. After listening, it became clear that the idea was missing an emotional direction, arrangement, vocal character, and sense of movement.

The generated track made the gaps visible.

That is where tools like DeepSong are most interesting. They shorten the distance between imagining and evaluating. The human part of the process remains: choosing the idea, recognizing what feels wrong, rewriting it, and deciding when the result finally says what it was meant to say.

The blank page is still there. It just makes sound now.