DEV Community: Meng Li

Not Every Useful Web App Is an AI Tool: What I'm Curating on AINavly

Meng Li — Sat, 24 Oct 2026 11:04:17 +0000

A directory can have hundreds of links and still leave you wondering what to click.

That's something I've been thinking about while working on AINavly, a curated directory of useful projects from around the web. Despite the name, it isn't only about AI. There are plenty of small web apps and browser games worth discovering, too.

The question I'm trying to answer isn't "How many tools can I list?" It's "Can someone look at an entry and quickly decide whether this is worth their time?"

Here's what belongs in the collection, and how I think about choosing it.

1. AI tools with a clear job to do

AI is the obvious starting point, but "uses AI" isn't a useful category by itself.

I'm interested in tools that help with specific tasks:

Chat and research: ChatGPT, Claude, and Perplexity represent different ways to ask questions, work through ideas, or find sources.
Coding: Cursor and newer AI coding products belong here when there's a clear development workflow to explain.
Images and creative work: Midjourney and other visual tools are easier to evaluate when you know what kind of output you're trying to make.
Writing and productivity: Tools such as Notion AI are most useful when their role in an existing workflow is clear.

The directory's submission categories also make room for AI video, audio, writing, agents, marketing, and model APIs. That doesn't mean every category is equally full today; it's the scope of projects I want to be able to evaluate.

2. Small web apps that solve surprisingly specific problems

Some of the most interesting projects don't need an AI label at all.

A browser-based embroidery lettering tool, a digital flower-gift builder, or a controller calibration utility might serve a narrow audience. But if it solves a real problem, that's enough reason to look closer.

Projects already featured on AINavly include Stitch Typewriter, Bloomify, Learn Arduino, and DualShock Calibration GUI. They don't all belong to the same industry, and that's the point: usefulness is more important than fitting a trendy label.

For this group, I want to explain what someone can actually do on the site, whether it requires an account, and what limitations to check before investing time in it.

3. Browser games and unusual interactive projects

I also include games that run in the browser.

They range from quick experiments to more involved projects: CrazyCattle3D, Brisbane Streets, Busy Nurse, and Mela Chaloge are a few examples in the current collection.

Game listings need different information from productivity tools. Instead of promising that something will "boost efficiency," they should tell you things like:

What kind of game is it?
Can you play immediately, or is setup required?
What controls, languages, or save options are available?
Is this the original project, a fan-made version, or an unofficial mirror?

Sometimes knowing what not to expect is the most useful part of a listing.

4. Projects can come from anywhere

A useful tool doesn't have to live on a polished company domain. Interesting projects show up on Vercel, GitHub Pages, Cloudflare Pages, and independent sites.

That creates a discovery problem: two projects may have similar names, one might have moved, and another might be an outdated demo. A directory should help people find the right destination, not just repeat whatever URL happens to rank in search.

AINavly's main site covers projects across the wider web. There's also a sister directory focused more specifically on Vercel-hosted discoveries. The overlap is intentional, but each listing should be written for the audience using that directory.

5. What makes a project worth listing?

I don't think a listing should be just a logo, a one-line pitch, and a button.

These are the questions I try to answer:

What does it actually do? Give a concrete use case, not a collection of buzzwords.
How do you start? Explain the basic steps or access requirements.
What should users know first? Mention pricing, language limitations, privacy considerations, or anything else that affects the decision.
Is the source clear? Link to the relevant official project and distinguish it from lookalikes when necessary.
What are the alternatives? Give readers enough context to choose, rather than pushing them toward a single option.

Submissions are reviewed rather than automatically published. Broken links, duplicates, misleading claims, and harmful projects aren't the kind of entries I want to add just to grow a number on the homepage.

6. The hard part is keeping the directory useful

Adding a new card is easy. Keeping it useful after a project changes its name, pricing, features, or URL is the real work.

That's why I think when something was added, when its description was updated, and when its source was checked are different pieces of information. A recent editorial edit doesn't automatically mean every product claim was retested.

I'm still learning what makes a directory genuinely useful, but one lesson is already clear: the number of links isn't the product. The context around those links is.

If you've built or regularly used a tool directory, what information do you look for before opening a project you've never heard of?

How I Built a Tool Directory with Astro and Cloudflare Pages

Meng Li — Sat, 24 Oct 2026 10:41:45 +0000

A tool directory sounds simple: store some links, put them into categories, and add a search box.

Then you start adding tools. You need individual pages, pagination, working links, useful descriptions, and a way to ship updates without turning the project into a maintenance job.

That's the problem I've been working through with NavSprout, a small directory of web tools, creative apps, and browser-based projects.

I chose Astro for the content-heavy pages and Cloudflare Pages for deployment. Here's what has mattered so far—and what I'd do differently if I started again.

1. Static first, interactive where it counts

Most visitors come to a directory to do one of three things:

Discover something useful.
Check whether it fits their task.
Open the original tool.

None of those steps needs a server-rendered page for every request.

Astro makes a good default for this kind of site: generate the content pages ahead of time, then add client-side behavior only where it helps. On NavSprout, the directory includes filtering, search, saved tools, and comparisons, but the actual tool information should still be readable without waiting for a large JavaScript application to boot.

The important distinction is static content doesn't mean a static experience.

2. The data model matters more than the cards

My first instinct with a directory was to focus on the layout. In practice, deciding what information belongs to each tool entry matters much more.

A useful profile should answer:

What does this tool actually help me do?
Who is it a good fit for?
Why was it included?
What should I check before using it?
Where is the official source?

Here's a simplified example of the kind of structured data that supports those questions—not a copy of my production schema:

type Tool = {
  slug: string;
  name: string;
  category: string;
  useCase: string;
  whyHere: string;
  officialUrl: string;
  limitations?: string[];
};

A directory page can look nice and still be unhelpful. The goal is to give someone a reason to click—or a reason to skip a tool that isn't right for them.

3. Static pagination without manually reshuffling pages

Pagination was one of the first problems I had to think through.

If new entries appear first, adding one tool changes which items belong on page 1, page 2, and so on. I didn't want to manually maintain those pages.

Astro's paginate() function handles the page generation at build time. The following is an illustrative version of the pattern, using 12 items per page:

---
// Example: src/pages/[...page].astro
import { tools } from '../data/tools';

export function getStaticPaths({ paginate }) {
  const newestFirst = [...tools].sort(
    (a, b) => Date.parse(b.addedAt) - Date.parse(a.addedAt)
  );

  return paginate(newestFirst, { pageSize: 12 });
}

const { page } = Astro.props;
---

<section>
  {page.data.map((tool) => (
    <a href={`/tools/${tool.slug}/`}>{tool.name}</a>
  ))}
</section>

<nav aria-label="Pagination">
  {page.url.prev && <a href={page.url.prev}>Previous</a>}
  <span>Page {page.currentPage} of {page.lastPage}</span>
  {page.url.next && <a href={page.url.next}>Next</a>}
</nav>

With a rest parameter route like [...page].astro, the first page can live at /, followed by /2/, /3/, and so on. When the dataset changes, the next build regenerates the appropriate pages.

One detail worth keeping separate: paginated listing URLs are not the identity of a tool. Each tool should have its own stable, descriptive URL, so an item moving from page 1 to page 2 doesn't change its permanent address.

4. SEO: a directory needs more than lots of URLs

It's easy to generate hundreds of pages with Astro. It's much harder to make those pages worth visiting.

A few decisions have been especially important to me:

Give detail pages a real job. A tool page shouldn't just repeat its homepage tagline. Include the use case, selection rationale, source links, and limitations where known.

Use normal HTML links. Pagination and tool detail links should be actual anchors, not destinations that only appear after JavaScript runs.

Keep metadata specific. Titles and descriptions should reflect the individual tool or category. Avoid giving every page the same generic SEO copy.

Treat pagination honestly. Page 2 contains different tools from page 1, so it shouldn't automatically canonicalize to page 1. Each indexable listing page needs a sensible canonical strategy.

Don't confuse more pages with more value. If two entries describe essentially the same thing, adding both doesn't make the directory more useful.

A sitemap helps search engines discover generated routes, but it doesn't replace thoughtful internal linking or good content.

5. Deploying with Cloudflare Pages

For a mostly static Astro site, the deployment setup can be wonderfully boring.

The standard Cloudflare Pages configuration is:

Setting	Value
Build command	`npm run build`
Output directory	`dist`
Production branch	`main` (or your chosen branch)

With the repository connected, pushing a content update can trigger a new build and deployment. Preview deployments are useful for catching broken routes, bad metadata, or unexpected pagination changes before they go live.

The bigger benefit is operational simplicity. I don't want to manage a server just to serve directory pages. If I add something that genuinely needs a dynamic backend, I can evaluate that separately rather than making the entire site dynamic from day one.

6. What I'd pay attention to next

As the number of tools grows, the challenges shift:

Content quality: keeping entries accurate as products change.
Discovery: helping people find the right tool without scrolling through endless cards.
Build health: catching duplicate slugs, broken links, and missing metadata before deployment.
Useful signals: learning which pages actually help visitors, not just which pages get impressions.

If I were starting a directory today, I'd still choose a static-first approach. But I'd design the content schema and URL structure before polishing the homepage.

The main lesson so far: a directory is a content system first and a collection of links second.

If you've built a directory with Astro, I'm curious how you handle updates and pagination once the catalog grows.