Building a 2,135-Project Static Showcase (No Database, No Framework, No Regrets)

Shayan Ali — Fri, 06 Nov 2026 12:11:27 +0000

Building a 2,135-Project Static Showcase (No Database, No Framework, No Regrets)

How LibreAI — a catalogue of 2,135 verified open-source AI projects with install guides, search and favourites — ships as pure static files.

LibreAI catalogues 2,135 open-source AI projects across 17 categories. Every project has its own page: what it does, who it's for, key features, an install guide derived from the project's README, alternatives, and an FAQ. The whole thing exists in 7 language editions — roughly 15,000 pages. There is no database, no server-side rendering, and no JavaScript framework. A Python build script generates flat HTML, and a static host serves it.

This post is about why that architecture won, and what it costs.

The data is code

The catalogue lives in Python data modules — lists of dicts, one per project, concatenated in a fixed order at build time:

REPOS = REPOS_CORE + EXTRA + V3 + EXTRA2 + ... + EXTRA11

Each record carries the fields the pages need: name, GitHub URL, category, tagline, description, features, licence, stars, forks, last-push date, the project's own website, alternatives, and — for 1,126 of the projects — a run block with install steps distilled from the project's README.

Data-as-code sounds primitive until you list what it buys:

Validation is free. A build either renders a record or throws. There is no "row in a weird state" because there are no rows.
Derived statistics are trivial. Our statistics page (star distributions, licence breakdowns, per-category counts) is computed from the same REPOS list the pages are built from — one source of truth, zero chance of the stats page disagreeing with the catalogue.
Diffs are reviewable. Adding a weekly batch of projects is a diff in a data file, readable by a human before it ships.

The cost is real too: the data files are enormous, and you must never line-edit a generated single-line file by hand. We learned to treat data modules as append-only artefacts with tooling around them, not as documents.

Verification is a pipeline step, not a vibe

Every project in the catalogue was verified against GitHub at intake: the repo exists, the licence is what we say it is, the star/fork counts and last-push date are recorded from the repo itself. Those recorded values are a snapshot, and the site is honest about that — the statistics page dates itself ("October 2026") and the methodology note explains that "pushed in 2026" is a property of the snapshot, not a live query.

That honesty is an architectural feature. A static site cannot pretend to be live data; designing around a dated snapshot forces you to say exactly what you know and when you knew it. 96.5% of the snapshot's 2,123 projects (the count at snapshot time; the catalogue has since grown to 2,135) had recorded a push in 2026 — a claim we can only make because the verification step stored the field.

Generating 15,000 pages without hating your life

The build is one Python program that walks the data and writes files: a page per project per edition, category hubs, the statistics page, sitemaps, feeds. The engineering rules that kept it sane:

One template function, no template engine. Pages are built by a handful of Python functions returning strings. Boring, debuggable, and fast enough — a full build is minutes, not a CI event.
Never regenerate what you can't verify. After each build we check the output tree: page counts per edition, sitemap coverage, and spot-checks that a repo page's install guide matches its record. Static generation fails silently in the worst way (a missing page is just… missing), so the checks are part of the build, not an afterthought.
Deploys are chunked file uploads, and payloads have hard limits. Our deploy route rejects payloads above ~129 KB per file, so the build keeps individual files small and the deployer uploads file-by-file with digests. This constraint quietly improves the site: no giant bundled anything, ever.

The two dynamic features, and how static survived them

A showcase needs favourites and a "request a project" form — the only two genuinely dynamic features. Both live in Supabase: an anonymous-key client talks directly from the browser, with row-level rules doing the guarding. The static pages don't know or care; if Supabase is down, the catalogue still renders perfectly and only the star button sulks. That's the correct failure hierarchy for a content site: reading is the product, interaction is garnish.

Search is the other obvious question. At 2,135 records, a pre-built static index plus a few kilobytes of vanilla JS beats a search backend on every axis that matters here: latency, cost, and the dignity of not running infrastructure to grep a list.

What I'd tell someone building a directory today

Start with the data model and the verification step; the pages are the easy part. Publish your methodology and date your snapshots. Compute your marketing statistics from the same data you render, so you can never accidentally lie. And pick the boring stack on purpose: the interesting problem in a directory is coverage and correctness, and every hour not spent on framework churn is an hour spent verifying the next hundred projects.

LibreAI is live at libreaihub.vercel.app — 2,135 projects, 17 categories, 1,126 install guides. The statistics page is generated from the catalogue data itself, if you'd like to check the arithmetic behind this post.

DEV Community: Shayan Ali

Building a 2,135-Project Static Showcase (No Database, No Framework, No Regrets)

Building a 2,135-Project Static Showcase (No Database, No Framework, No Regrets)

The data is code

Verification is a pipeline step, not a vibe

Generating 15,000 pages without hating your life

The two dynamic features, and how static survived them

What I'd tell someone building a directory today