The problem
A nutritionist’s plan arrives as a PDF. To follow it, someone has to turn it into a menu, a shopping list and a cooking plan each week, and it gets harder when a household has more than one plan.
Next: What I didWhat I did
I built one path: PDF, reviewed draft, confirmed plan, weekly menu. Three decisions shape it:
PyMuPDF and Tesseract OCR extract the text on the machine, in Portuguese and English. A model only interprets layouts the local parser can’t.
The owner reviews and confirms every reading. Missing amounts and uncertain readings block confirmation instead of being guessed.
Menus, shopping totals and prep plans are computed by ordinary code, so the same confirmed plan gives the same result.
Cost is held down by design: automated tests never call the paid API, and manual tests are capped at $0.50 a day in the app itself.
Next: Where it standsWhere it stands
The software is verified offline, with unit and integration tests and a browser run of the whole workflow, including at phone width.
Confirming a real plan is still blocked by ambiguities in the source document, which is the check doing its job. Nutritionist validation and a pilot with 3–5 people are ahead.
Next: What I'd do nextWhat I'd do next
Clear the real-plan blockers. Make it possible to resolve each ambiguity in review, without weakening the block.
Validate with a nutritionist. Their judgement decides whether the reading is good enough to rely on.
Run the pilot. A small group using it for real weeks is what will show whether it saves time.