I’ve been thinking a lot about how to synchronize data between the MealMind server and clients. The proof of concept app I have is a web app and there isn’t any persistent state once you navigate away from the app. For the “real” version, I feel like it has to be a mobile app. For shopping, I’d rather have the shopping list on my iPhone and for planning, it’d be easier to actually drag and drop on an iPad. Some people may prefer a web interface, so it’ll likely exist as well, but I think this is definitely a good case for a “mobile first” approach to getting the thing launched.

I wouldn’t mind making it a progressive web app (PWA) since that would certainly solve the issue of needing to build for iOS AND Android, but I’m not really convinced that PWAs are ready for prime time when you’re talking about an app like this. I can definitely see the app being used on multiple devices for the same account. I don’t know if people will use the app simultaneously though. Would a couple each open the app on their devices, sign in, and start meal planning together? Or would one person make the plan and the other may view it, but only one is really making changes. Same for the shopping list – if a couple goes shopping, will they split up and each mark things off the list or will one manage the list and the other focus on getting the item in the cart? Those sound like small differences, but it changes how the API has to work.

In the scenario where only one person is really making the changes at any given time, a “normal” REST-style API would work just fine. You don’t have to worry about multiple conflicting changes coming in at the same time since only one device is making the changes. That’s not to say it’s impossible to cause trouble – it’s still possible, but you can handle it by letting the server decide which change to keep (last one in, etc).

If, on the other hand, multiple devices can make changes at the same time to the same items, then you really have to think about keeping deltas for every change. For example, if a couple is entering recipes and one person is adding the ingredients and another person sees a typo in the recipe description, you would (responsibly so) expect the final recipe to have the correct description AND the correct list of ingredients. If you don’t track deltas for each piece of data that can change, you might end up either throwing away some of the ingredients or throwing away the typo correction.

The bad thing about all of this is syncing is really hard. I personally haven’t had to build out a true synchronization system, so I’ve been reading up on it. I’ve always been aware it’s one of those things that sounds easy but is incredibly hard. I’ve also heard (and can see how) it’s not something you can really do generically – so there isn’t an off the shelf sync solution you can just plugin in. That said, I’ve found Brent Simmons Vesper Sync Diaries to be incredibly enlightening. Brent has a handful of posts describing his thoughts as he worked out the sync process for the Vesper iOS app. It’s not the same data I would need to sync with MealMind, but many of the considerations & gotchas still apply.

At this point, I’m torn on how to proceed. On one hand, I kinda want to build out a shopping list app that uses a real sync so multiple devices can work with the data at once. I feel like the shopping list is the main place this scenario would happen so it would make sense to try to solve the hard problem first.

On the other hand, I’m tempted to start building out the app as a web app, almost like the proof of concept app, just so I can get it running and in the hands of other people. If I do that, it’ll be harder to later come back an integrate syncing though because you need pretty specific data structures to keep up with this stuff.

I think I’m going to stick with the web app initially and not deal with the real sync support initially. If I go down the mobile app + sync route right now, it’ll be months before I have anything to show. If I go the web app route, I can have something running in just a couple of months at most.

I’ve used the existing proof of concept app to plan & shop for our family meals for the last two weeks. So far, it’s actually been great. I’ve found a few more bugs/issues that I may try to fix for the next meal planning cycle, but I think the features are pretty usable as-is.

My favorite thing is that I can tell the system that I’ll be having 2 servings of an item per day. For example, keto fat bombs – I like to keep them at the office for snacks between meals. The recipe makes 12 of these at a time. The system is smart enough to see that 2 servings per day x 7 days is 14 servings, so that will require the recipe to be scaled up to 2x.

Based on that information, it can include the proper amount of ingredients on my shopping list so I’ll have 2x the ingredients for this specific recipe. It’s really handy. That also makes it easy to put the same meal on multiple days and the system knows which days are simply leftovers from earlier in the week.

None of this is rocket science at all, but I don’t see many meal planning systems taking this type of information into account. They all want you to schedule the meal and expect you’ll eat every serving that day. For us, we make bigger batches where we have plenty of leftovers. We make a chili that lasts a week in the freezer. It’s about saving time as well as saving money. So far, my experience has been that we’ve saved a ton of money by having a plan. Obviously, you don’t have to have a technology system for this, but it sure helps.

The one big downside that I need to solve for the public release (or at least not long after it) is that you need to input a good amount of data for this to work. You need a list of recipes, you need a list of your family members, the recipes need to specify how many servings they make, the ingredients need to be broken out so they can be parsed into a shopping list, (today) the ingredients have to be named the same so shopping list items get combined properly, etc. It’s just a lot of up-front data entry. Once that’s all in there, you just drag & drop to set up your plan and then one click to get your shopping list.

In the future, I think I can eliminate a lot of that manual work. I’m not sure it’ll totally go away, but the goal is to get people up and running as fast as possible. Lots of ideas to play around with there, but they’ll take a while to implement.

All in all, though, I’m very happy with how it’s working so far. Even if I didn’t take the idea any further, it’s been extremely helpful to my family, so the time spent has been well worth it. I think it can help lots of other families though and I’m excited to see what that looks like.