Car Catalog

Stack: Vanilla HTML · CSS · JavaScript · schema-versioned JSON dataset (v1.3) · no framework, no backend, no build step
Overview
A structured dataset and reference catalog of 1,492 vehicle trims across 435 models and 46 brands, with every spec field individually sourced and cited. Built as a vanilla-JavaScript single-page catalog that opens offline from file:// — no framework, no backend, no build step. The interesting work is in the data layer: schema-versioned JSON, a manufacturer-only source policy enforced per field, and a verification pipeline that flags coverage gaps and citation drift before release.
The catalog interface is the deliverable users see. The portfolio story is the dataset behind it and the discipline used to build it.
Key stats
- 46 brands
- 435 models
- 1,492 trims
- ~40 fields per row
- 98%+ MSRP completion
- ~73% manufacturer-sourced image coverage (structural ceiling under the source policy)
- Zero verification blockers at v1.3
- JD Power 2026 VDS reliability data, current
Technical approach
The data layer is a schema-versioned JSON dataset (v1.3). Each row covers a single trim and carries ~40 fields spanning powertrain, dimensions, performance, MSRP, image references, and a citation block tying every value back to a manufacturer source. The front end is plain HTML, CSS, and vanilla JavaScript — no React, no build tooling — so the catalog is fully portable and inspectable. The site can be opened directly from a local file path or served from any static host.
Source policy: manufacturer-only. Third-party aggregators were rejected during ingestion. Every field has an associated citation in the schema, validated at build time.
Engineering discipline / verification system
The project was built across 16 chained Claude Code sessions, each with explicit safety rules, checkpoints, and verification gates. This was a deliberate workflow choice: small, scoped sessions with hard stops between phases produce a clearer audit trail than one long agentic run, and the verification gates catch regressions before they propagate.
Two moments worth highlighting:
- Session 9 — regex separator bug. A field-parsing regex was silently misparsing a separator character across multiple brands, producing data that looked plausible but was wrong on the margins. The bug was caught by the row-level spot-check guard during a verification gate and fixed before release.
- Session 15 — anti-bot poisoning. A manufacturer source had quietly started serving altered values to automated requests. The spot-check guard caught the discrepancy, the affected ingestion run was reverted using the per-session
.baksnapshots, and the ingest path was changed to bypass the poisoned route.
These are the kinds of failures that don't show up in summary metrics — they show up in row-level audits. The verification system was scoped explicitly to surface them.
Example analyses
Three short analytical writeups are included in the catalog repo, demonstrating use of the dataset as an analysis substrate rather than just a browsing tool:
- Price-performance landscape. Plug-in hybrids cluster heavily at the $120K+ luxury performance tier — PHEV technology is being deployed as a performance multiplier on top-end vehicles rather than as a mass-market efficiency play.
- Brand reliability rankings. Using JD Power 2026 VDS data: Lexus ranks #1, Volkswagen ranks last. The full ordering and the gap between tiers are in the writeup.
- EV market positioning. The Lucid Air leads on range at 512 miles. The writeup maps each EV in the dataset against price, range, and segment, surfacing which manufacturers are competing on which axes.
Honest limitations
- Image coverage ceiling. Manufacturer-only sourcing caps photographic coverage at ~73%. Lifting the ceiling would require relaxing the source policy, which would compromise the citation discipline the rest of the project depends on.
- Snapshot, not a feed. The dataset is a point-in-time snapshot at v1.3. Trims change across model years; the catalog reflects current production at the time of capture and is not auto-refreshed.
- No backend. All filtering and comparison runs client-side over the JSON dataset. The architecture is intentional but means there is no query layer for ad-hoc analysis beyond what the UI exposes.
- Scope of analyses. The three included writeups are illustrative rather than exhaustive. Many other slices of the data would reward closer inspection.
Built by Jonathan Nadeau.
Live demo · GitHub source · nadeau.jonny@gmail.com · linkedin.com/in/nadeau-jonathan