Making LEGO's Instruction Archive Searchable Without a Backend
A static search engine over 7,447 LEGO sets and 11,696 instruction PDFs that ships in 561 KB with no server behind it.
LEGO publishes decades of building instructions, but there is no good way to search across them. BrickDB fixes that. It is a search engine over 7,447 LEGO sets going back to 1980, filterable by category, year, parts count, instruction type, and more. You can try it at bricks.party.
The data behind it
The raw material is LEGO's own instruction archive: 11,696 PDFs spanning 264,709 pages. That got pulled together into a single searchable index of sets, each carrying the metadata a collector or builder actually filters on. The result covers 136 categories, and every one of the 7,447 sets lands in a category. Nothing is left uncategorized.
Getting to zero uncategorized sets was not free. The source data from Rebrickable ships theme IDs with no human-readable names attached. An ID tells you two sets share a theme, but not what that theme is. So the build step votes on them, inferring names from the sets grouped under each ID rather than leaving raw numbers in the interface. That voting pass is what turns a pile of anonymous IDs into 136 named, browsable categories.
No backend, on purpose
The interesting engineering choice is what BrickDB does not have: a server. There is no API, no database process, no query endpoint. The entire searchable dataset ships to the browser as a static payload, 561 KB over the wire, and every filter runs client-side.
That constraint shapes everything upstream. All the heavy work, parsing the PDFs, resolving categories, voting on theme names, has to happen once at build time, because there is nothing running at request time to do it later. What the browser receives is already finished. The payoff is a site that stays instant no matter how many people hit it, costs almost nothing to host, and cannot go down in the way a backend can.
For a dataset this size, 561 KB is the headline. It means the whole LEGO catalog, filterable across 136 categories and four and a half decades, fits in less than a megabyte of static assets. This is another entry in the Moonshine Labs pattern of pushing real work into the build step so the runtime can stay dumb and fast.
Have something that needs building, or stabilizing?
These notes are the work log. The paid work runs through Moonshine Labs, my product and engineering studio. Tell us what you're building, or grab a call.
Work with us →