Building EatNeat：餐單、温和提醒與支援型吉祥物

I’m building EatNeat, a mobile app that helps people turn a nutrition plan into a manageable routine—before “What should I eat?” takes over the evening.

A lot of meal-planning tools focus on creating a plan. I’m focused on what comes after: remembering it, finding something practical when hunger clocks in, and tracking what you ate without turning dinner into a spreadsheet assignment.

EatNeat is still a prototype. Here’s what’s working, what I’m figuring out, and how the mascot Bitey provides moral support.

The core loop

The app is organized around a simple cycle:

1. Create a meal plan or bring in an existing one.
2. See the day’s meals and get reminders at their scheduled times.
3. Browse meal ideas that match selected constraints.
4. Capture or mark a meal as eaten.
5. Review progress over the day and across recent days.

The Today screen brings schedule and progress together. Meals can be marked eaten when their scheduled time arrives, and progress includes estimated nutrition metrics. The user stays in control; the app helps without handing out gold stars for lunch.

AI as a helper, not the whole app

EatNeat has AI-assisted flows for personalized plans, meal recommendations, recipes, and optional photos. Requests include selected filters and nutrition targets. Practical constraints are requirements: an “under 15 minutes” meal can’t hide a 40-minute oven step, and equipment filters should match the actual cooking method.

Food photos are optional and handled separately from meal text. Without a photo, the meal still appears with a bundled animation or illustration. The recipe shouldn’t vanish because its glamour shot is late.

The app can call configured service endpoints. During local development, some AI flows can call Gemini directly with a development environment key. A production app should route requests through an authenticated server and keep provider keys off the client.

AI nutrition values are estimates. EatNeat is not a medical tool, and the prototype does not treat a missed meal as a failure or make clinical recommendations.

Local-first state and reminders

Plans and meal logs are stored on-device with AsyncStorage. Writes are debounced and serialized, and local notifications remind users at planned meal times—because remembering breakfast shouldn’t require remembering to remember breakfast.

Private meal-log photos stay on-device. If a user uploads a plan photo for parsing, it goes to the configured plan-reading service, with that made clear before upload.

The stack

The current app uses:

• Expo and React Native for the mobile app
• Expo Router for file-based navigation
• TypeScript for app screens, state, services, and UI components
• React Native Paper for a small set of interface components
• Reanimated for navigation and interface motion
• AsyncStorage for local plan and log persistence
• Expo Notifications for scheduled meal reminders

What is still a prototype

The accountability feed displays sample posts and does not publish to a social service. Some preview screens use illustrative nutrition data. The app doesn’t ship a backend, so server-based AI features need a configured endpoint. For now, the social circle is supportive and fictional.

I’m also breaking larger screens into focused components. The Today screen’s progress visualization and schedule calculations now live outside its route file, making the daily flow easier to evolve.

What I’m learning

The most useful decision so far: keep the basic habit loop independent of AI. Meal ideas work without generated photos; logging works without image analysis; plans can be reviewed when a service is down. A flaky model shouldn’t get veto power over lunch.

AI can add convenience, but a slow request or missing key shouldn’t block the everyday action. The meal still exists even if the pixels don’t.

EatNeat is under active development. I’m currently refining the meal flow, reminders, and progress UI while building toward a more complete, privacy-conscious backend.

If you’re building a habit-focused app, I’d love to hear how you decide which parts should depend on AI and which should keep working on their own.