vincent@portfolio: ~
lc250-tracker — schema.prisma
← cd ..

LC250 Build Tracker

personal project

A build log for a Toyota Land Cruiser 250 that behaves like a real system of record: every part carries fitment, weight, and cost, every spec links back to the source it came from, and the payload budget recalculates as the build changes. An LLM does the extraction; the schema does the arguing.

role ·
everything
years ·
2026
why ·
product sense outside work hours
Build tracker dashboard screenshot

problem

Build knowledge for a new platform lives in forum threads, vendor pages, and other people's spreadsheets. Fitment is implied, weights are missing, and nobody tracks what a build does to payload until the truck is over GVWR. The data exists — it is just unstructured and uncited.

approach

  • Schema first. Parts, fitments, install events, and citations are modelled in Prisma — the LLM fills records, it does not define truth.
  • Cited extraction. Vendor and forum pages go through Claude with a structured output contract; any spec without a source URL is rejected rather than guessed.
  • Budgets that recompute. Weight, payload headroom against GVWR, and running cost update on every change, so the tradeoff of the next mod is always visible.
  • Boring deployment. Next.js on Vercel, SQLite/Turso, no ops — the point was to ship, not to operate it.

outcome

One place that answers "will it fit, what does it weigh, what does it cost, and where did that number come from" — and a small proof that AI extraction is useful precisely when it is fenced in by a schema and forced to cite.

prisma/schema.prisma
model Part {
  id         String     @id @default(cuid())
  name       String
  category   Category
  weightKg   Float?     // null until cited
  priceCad   Int?
  fitments   Fitment[]  // LC250 trim + year range
  citations  Citation[] // every spec traces to a source
  installs   Install[]
}

screens

  • Weight / payload budget view
  • Part detail with citations