The meal planner started as a personal problem. Every Sunday evening we'd have the same conversation — what are we eating this week, what do we need to buy, who's cooking what. It took longer than it needed to, and we'd still forget something at the supermarket on Tuesday.
We looked at existing meal planning apps. There are a lot of them. Most were either too complicated — full nutrition tracking, macros, calorie counting, social features, syncing with fitness platforms — or too simple, basically a notes app with a calendar view. We wanted something in the middle: plan a week of meals, generate a shopping list, keep it simple.
So we built it.
The problem we were actually solving
It's worth being specific about what the problem was, because it shaped every decision we made. The problem wasn't nutrition. It wasn't discovering new recipes. It wasn't tracking what we ate. The problem was coordination — deciding in advance what meals were happening across the week so we could shop once and not stand in the kitchen on Thursday wondering what's for dinner.
That's a narrow problem. A narrow problem is a good problem to build for, because you can solve it completely without scope expanding forever.
Why Flutter
We chose Flutter because we build in Flutter. It runs well on Android, the development experience is fast, and a single codebase covers what we needed. For a focused app with a clean UI, Flutter is an excellent fit — you get a lot of control over the visual design without fighting a framework that wants to do things a particular way.
The app is Android only. Most of our users are on Android. We didn't want to maintain an iOS build for no clear benefit at the time of launch.
The decision to store everything locally
The meal database is local — no server dependency, no subscription, no account required. This was a deliberate choice and it's the one we're most satisfied with in retrospect.
Local storage means the app works offline. It means it's fast — no network requests on every interaction. It means there's no "we're shutting down the service" risk for users. It means we don't have to run a backend, maintain a database, handle authentication, or think about data breaches.
The trade-off is that there's no cross-device sync and no cloud backup. We decided that was acceptable for a meal planning app. Your meal plan lives on your phone. If you get a new phone, you set it up again. For most people, that's fine.
Features we cut
The original list of features was longer than what shipped. Here's what got cut and why:
- Community recipes — required a backend, moderation, accounts. Too much complexity for too little benefit in a personal planning tool.
- Nutritional tracking — a different problem from the one we were solving. Apps that do this well are built entirely around it. Adding it here would have made the app worse at its actual job.
- Photo uploads — photos for every meal sounds nice. In practice you end up with no photos because taking them is friction.
- Social sharing — nobody asked for this. It was on the list because it seemed like the kind of feature apps have, not because it solved a problem.
Every feature that got cut made the app better. That's not something you always believe when you're cutting it, but it's consistently true.
What shipping it felt like
Getting an app onto the Play Store for the first time involves more steps than you expect — the store listing, screenshots, content rating, privacy policy, waiting for review. But the process itself is manageable once you've done it once.
The first week of real users using something you built is a particular feeling. You watch the install numbers and wonder whether the people who installed it actually opened it, whether it did what they expected, whether it solved their problem. Some of them left reviews. Most of the reviews are positive. That's genuinely satisfying in a way that building something just for yourself isn't.
Victain's Meal Planner is on the Play Store now. It does what it says. That's the whole point.