BrickDB

LEGO publishes every building instruction it has ever printed, and makes almost none of it findable. BrickDB indexes 11,696 official PDFs — 264,709 pages across 7,447 sets, 1980 through 2026 — behind a search box that answers before you finish typing. There is no server. The entire database is one JSON file that gzips to 561 KB, sitting on GitHub Pages next to about 30 KB of application JavaScript.

The hard part was never the search. It was the taxonomy. Rebrickable's records carry a numeric theme_id and no theme name, and only part of the scraped corpus came with a human-readable category. So the build step derives the mapping: it tallies, for every theme ID, the category names used by the sets that do have one, and assigns each unlabelled set the plurality winner — with a dozen hand-added fallbacks for themes like One Piece and Bluey that appear only in Rebrickable's half of the data and never in the labelled half. Result: 1,025 full category paths, nested up to six levels, collapsed into 136 clickable facets, and not one of the 7,447 sets left uncategorized. Filtering uses prefix matching, so "Star Wars" catches Star Wars / Episode 9 without a tree widget.

Underneath the PDF search is a second index most visitors never notice: 7,389 sets ship LEGO Studio .io models, 748 ship LDraw, and 1,198 carry community-reconstructed digital builds — machine-readable geometry, not scans. 2,384 sets have more than one booklet (one has eighteen), and Alternative Build, Co-Build and Localized editions are separate, filterable things. All ten filters live in the URL, so any view is a link. And the whole toolchain was ported to run on an Android phone: esbuild's missing android-arm64 binary symlinked to the Linux one, Rollup's native binding swapped for its WASM build, and Vite driven through Bun's JS API because Termux's bionic-linked Node can't load lightningcss's glibc shared objects.