2026 — ongoing
shopping-receipts
Receipts arrive by scanner, email and export; they come out the other side as structured, categorised, queryable records.
Private repository — the writing here describes the approach rather than linking to code.
- TypeScript
- NestJS
- React
- SQLite
- Claude vision
A receipt is a hostile document. Thermal paper, inconsistent layout, a total that may or may not be the number you want, and a shop name abbreviated past recognition. They arrive scanned, emailed as PDFs, and exported in bulk from expense software.
This ingests all three, extracts the structured fields with Claude vision, files them by category, and exposes everything through an HTTP API and a web interface. Deduplication is by content hash, so the same receipt arriving twice by two routes lands once.
The architecture is deliberately the same as the other tools in the fleet — watch an inbox, extract, validate, file deterministically, store typed data, emit an event. Repeating the shape is the point: each new document type is a variation on a pattern that already works rather than a fresh problem.
It also carries a small convention I have come to rely on: when a session is working against the project, it announces itself in the terminal, so a second session knows to ask before writing. Two agents editing the same SQLite database is a problem best prevented rather than diagnosed.
The repository is private, since the contents are a complete record of what I buy.