The idea
You photograph the rating label on your furnace, dishwasher, water heater, and dryer. The app resolves each one to a make and model, finds the manufacturer's PDF manual, and extracts the maintenance schedule buried in it — filter every 90 days, anode rod inspection at 24 months, drain pump filter monthly. It writes those into a calendar with real dates, and pins the correct consumable part number to each task so the reminder comes with something you can actually order.
Why build this
The information exists and nobody uses it. Every appliance ships with a maintenance section, and it goes into a drawer within a week. The result is a water heater that dies at eight years instead of fifteen, and a dryer vent that becomes a fire report. This isn't a knowledge problem — the intervals are published — it's a retrieval and scheduling problem, which is exactly the kind of thing software is for.
The reason it's tractable now: model-number labels are short, high-contrast, fixed-format strings that a vision model reads reliably from a bad phone photo, and long-context extraction over a 200-page PDF costs a few cents. Five years ago you would have needed a manually curated database of appliance schedules per model, which is why every prior attempt at this was a spreadsheet with forty entries. Now the per-model work is one extraction call, cached forever.
Stack sketch
- Frontend: Next.js with the App Router, deployed on a single small VPS. Camera capture through a plain
<input type="file" capture>— no native app. - Label reading: Claude with an image in the message, prompted to return
{brand, model, serial, manufacture_date}as strict JSON. Fall back to a manual text field, because rating plates behind a water heater are genuinely unphotographable. - Manual retrieval: ManualsLib and Manua.ls have no usable API, so scrape per-brand support sites (Whirlpool, Bosch, Rheem, GE all expose a model-lookup endpoint that returns PDF links) and cache the file in object storage keyed by model.
- Extraction:
pdfplumberto pull text, then a single Claude call over the maintenance chapter returning a task list of{title, interval_days, part_number, procedure_summary, source_page}. Store the page number — the citation is what makes users trust it. - Storage: Postgres. Two tables that matter: a global
model_schedulecache shared across all users, and a per-userappliance+task_instancepair. - Delivery: an authenticated iCal feed per household, plus email via Resend. Do not build an in-app notification centre.
Scope for v1
In:
- Add an appliance by photo or by typing a model number.
- Automatic schedule extraction for the four highest-value categories: water heater, HVAC/furnace, dishwasher, dryer.
- A calendar view, a "mark done" button that reschedules from the completion date rather than the due date, and the iCal subscription link.
- The extracted procedure text shown inline with a link to the source PDF page.
Deliberately out: multi-property support, service-provider booking, parts checkout, warranty tracking, any smart-home integration, and anything that needs the user to enter a purchase date they don't remember.
Where it could go
The cache is the asset. After a few thousand appliances, you hold a structured maintenance schedule for most of the models in circulation in a given market, and that's worth more than the app around it. A read API for that dataset sells to home-inspection software, property managers, and home-warranty underwriters who currently have no machine-readable version of it.
The second path is landlords and small property managers, who have the same problem across thirty units and an actual budget. Same data model, different surface: a per-unit view, assignable tasks, and a compliance log they can hand a regulator or an insurer. The third, slower path is buying signals — a filter task firing on a known interval is a purchase intent event with a known part number, which is an affiliate business that doesn't require you to nag anyone.
Watch out for
Manufacturer manuals are copyrighted, so cache them for retrieval and link to the source rather than redistributing PDFs, and treat extracted schedules as facts you cite, not text you republish. The other risk is silent extraction failure: a model whose manual yields nothing must show as "no schedule found" with a manual-entry option, because an appliance that quietly appears healthy is worse than one you never added.