I built ReciPath because most recipe apps today have high monthly costs, overbearing social features, and require an internet connection just to see a shopping list.
THE APPROACH:
I’m primarily a Flutter developer. For this project, I wanted to experiment with a "database-driven UI" flow. Instead of heavy state management boilerplate, the UI state is tightly coupled to a local Drift (SQLite) DB. If it's in the DB, it's in the UI.
TECHNICAL HIGHLIGHTS:
- Offline First: Everything works locally. Accounts are optional and only used for syncing via Supabase.
- Shopping Planner: You select recipes, and the app generates a shopping list.
- Smart Timers: When you start a recipe, it tracks your actual cooking time to provide better averages later. It also handles per-step timers (e.g., a 60-minute oven timer) with local notifications and sounds.
- The Sharing Challenge: Since the app is self-contained, sharing recipes is currently done via JSON files. The hard part is mapping imported "grocery items" to local ones. The app tries to match by barcode and name, but I’d love to hear ideas on how to streamline this mapping process.
ROADMAP: BYOT AI INTEGRATION
- I'm currently looking into adding "Bring Your Own Token" AI support. The goal is to let users use their own API keys (OpenRouter/OpenAI/etc.) to import recipes directly from messy URLs or photos of physical cookbooks. Since recipe sites change their HTML constantly, using LLMs for schema mapping feels like the most robust way to keep the app lightweight without writing a thousand custom scrapers.
WHY OPEN SOURCE?
I was just tired of the bloat. I wanted a clean, open-source alternative that belongs to the user, not a subscription service.
I’d love feedback on the UX, the Drift-heavy architecture, or your thoughts on the recipe-sharing schema!
cunibon•1h ago
THE APPROACH: I’m primarily a Flutter developer. For this project, I wanted to experiment with a "database-driven UI" flow. Instead of heavy state management boilerplate, the UI state is tightly coupled to a local Drift (SQLite) DB. If it's in the DB, it's in the UI.
TECHNICAL HIGHLIGHTS:
- Offline First: Everything works locally. Accounts are optional and only used for syncing via Supabase. - Shopping Planner: You select recipes, and the app generates a shopping list. - Smart Timers: When you start a recipe, it tracks your actual cooking time to provide better averages later. It also handles per-step timers (e.g., a 60-minute oven timer) with local notifications and sounds. - The Sharing Challenge: Since the app is self-contained, sharing recipes is currently done via JSON files. The hard part is mapping imported "grocery items" to local ones. The app tries to match by barcode and name, but I’d love to hear ideas on how to streamline this mapping process.
ROADMAP: BYOT AI INTEGRATION
- I'm currently looking into adding "Bring Your Own Token" AI support. The goal is to let users use their own API keys (OpenRouter/OpenAI/etc.) to import recipes directly from messy URLs or photos of physical cookbooks. Since recipe sites change their HTML constantly, using LLMs for schema mapping feels like the most robust way to keep the app lightweight without writing a thousand custom scrapers.
WHY OPEN SOURCE? I was just tired of the bloat. I wanted a clean, open-source alternative that belongs to the user, not a subscription service.
I’d love feedback on the UX, the Drift-heavy architecture, or your thoughts on the recipe-sharing schema!
GitHub: https://github.com/Cunibon/recipath Play Store: https://play.google.com/store/apps/details?id=com.cunibongam...