By leveraging Next.js static generation (SSG), every single comparison page and tool detail page is compiled to static HTML at build time. This means sub-millisecond load times and perfect SEO right out of the box.
Client-Side Filtering with No Latency
Because the dataset is loaded as a static asset, I could implement instant, client-side fuzzy searching and category filtering without triggering server API calls.
Using basic React state and useMemo, filtering through 70+ items happens instantly as the user types:
const filteredTools = useMemo(() => {
return tools.filter(tool => {
const matchesSearch = tool.name.toLowerCase().includes(searchQuery.toLowerCase()) ||
tool.description.toLowerCase().includes(searchQuery.toLowerCase());
const matchesCategory = selectedCategory === 'All' || tool.categories.includes(selectedCategory);
return matchesSearch && matchesCategory;
});
}, [searchQuery, selectedCategory]);
SEO Optimization at Scale
For directories, search engine traffic is life. I implemented dynamic metadata rendering using Next.js generateMetadata API to automatically create unique title tags, open-graph cards, and structured JSON-LD schemas for each of the 70+ tools. This ensures search engines easily index the reviews and comparisons.
You can check out the live site here: https://aitexttools.net
I would love to hear your feedback on the architecture! How do you handle static search indexing for your directory projects? Let me know in the comments below.
Top comments (1)
Static JSON + Next.js for a directory is the correct boring choice and worth defending against the instinct to reach for a database. At 70 (or even a few thousand) entries that don't change every minute, a build-time static dataset gives you instant page loads, trivial hosting, zero query latency, and nothing to keep running - a DB would add operational weight for zero benefit at this scale. People reach for Postgres reflexively when a JSON file and SSG would be faster, cheaper, and simpler. Matching the data layer to the actual access pattern (read-heavy, rarely-changing, small) is good engineering judgment, not a shortcut.
The instinct I like here is the same one I bias toward: don't add infrastructure the problem doesn't require. It's how I think about Moonshift, the thing I work on - a multi-agent pipeline that takes a prompt to a deployed SaaS - favoring the simplest thing that fits over reflexive complexity. Directory sites are also a nice SEO/distribution play, which is the other half of the game. Multi-model routing keeps a build ~$3 flat, first run free no card. Clean build. What's your update flow when the 70 becomes 700 - rebuild on a content commit, or a lightweight CMS feeding the JSON? The "static until it isn't" threshold is the one decision I'd think about before it grows.