Personal product
Itemize
A self-hostable household inventory app that turns photos into reviewable item proposals. A two-pass Gemini pipeline identifies objects and extracts metadata; users can correct, accept, or reject the results, then find their belongings through full-text and fuzzy search.
- Status
- Active
- Signal
- Connects photo capture, editable item proposals, and searchable inventory records in one workflow, with workspace-scoped access and a self-hostable application stack.
- Focus
- Applied AI · Computer vision · Self-hosting
The premise
Inventory software is usually designed for warehouses. Itemize starts with a different environment: ordinary people trying to remember what they own, where it is, and how to find it again without turning their home into a cataloging project.
The central workflow is photo-assisted capture. Instead of asking someone to enter every item from scratch, the application proposes records from a photo and gives the user a deliberate review step before those proposals become inventory.
From photo to inventory
The backend validates an uploaded image, saves the original first, and generates display and thumbnail variants with Sharp. A two-pass Gemini 2.5 Flash pipeline identifies objects and their bounding boxes, then extracts item metadata from cropped regions. Sharp handles the crops and WebP assets; the recognition work comes from the hosted model, not a custom-trained segmentation network.
The review interface pairs the source photo and bounding-box overlays with proposed items. Users can edit extracted fields, accept or reject individual proposals, or accept them together. Delayed actions provide an undo window. Acceptance is connected to the backend: it creates the inventory record, attaches the cropped image and metadata, and updates the proposal's status.
Architecture and retrieval
The frontend uses React, Vite, and TanStack Router. A Fastify backend exposes a Mercurius GraphQL API and upload routes, with Better Auth session handling and workspace membership checks. Drizzle ORM maps the inventory data to PostgreSQL, while a storage-provider abstraction currently writes image assets to the local filesystem.
Retrieval complements the capture workflow with full-text and fuzzy matching. The current implementation uses lexical search rather than an embedding model or vector database. That distinction matters: the application already supports finding structured inventory records, but semantic retrieval is not an implemented capability to claim here.
What self-hosting means here
The production configuration packages the API and built frontend in one application container behind Traefik, with PostgreSQL running separately. This keeps the application and inventory storage under the operator's control, but it does not make the image-processing workflow fully offline: AI extraction sends images to Google's Gemini API.
The pipeline records stages, token usage, cost, and latency. It retries extraction with a simplified prompt when needed, rather than silently switching to another model provider. These operational details are part of making model-assisted capture understandable and maintainable.
What I am learning
The interesting engineering boundary is between a plausible model response and a trustworthy inventory record. Saving source images, keeping proposals separate from accepted items, supporting corrections, and recording the cost of extraction are as important as recognizing an object. Itemize is still in development; recognition accuracy, retrieval quality, and real-world time savings need evaluation before they become performance claims.