Problem
Planning a week of meals means balancing preferences, finding recipes, and making the same decisions repeatedly. Cook brings that workflow into one place.
Constraints
Generated plans must fit seven days and twenty-one meal slots. Third-party services can fail, and private meal plans and billing data need clear ownership boundaries.
Approach
Milo collects three answers before generating a structured plan. Zod validates the output, and a deterministic fallback keeps planning available when the model fails. Concurrent recipe searches use Promise.allSettled so one unavailable source does not discard the other result.
Architecture
React and TypeScript → Express REST API → MongoDB. The server connects to OpenRouter through the Vercel AI SDK, recipe providers, and Stripe. Provider keys remain server-side.
Challenges and trade-offs
An LLM makes planning flexible but introduces uncertainty. Schema validation and a deterministic fallback trade some variety for predictable behavior. JWT authentication, bcrypt, ownership checks, rate limits, and signed billing webhooks protect the application boundaries.
Results
The application includes eight pages and more than twenty REST endpoints, with a conversational flow that creates a seven-day plan. These are implementation facts, not claims about adoption.
What I would do next
Measure the quality of generated meal plans with repeatable evaluation cases, especially dietary constraints and provider failures.