Making MealMind #8: No Progress

I had more going on this week than I planned, so I didn’t get a chance to make any progress. I’m hoping to get things back in gear this coming week. I had a good amount of momentum going when I built the proof of concept app, but I need to rebuild that momentum for this version. At the very least, I’d like to get a marketing page up for MealMind even if I don’t make much progress on building the backend features.

I did start thinking about building the mobile app again though. I think one of the critical features as far as adoption goes is to get recipes into the system quick & easy. With the proof of concept, I have to type in each ingredient, break up the quantity, units, and description and all of that. I’m not even capturing the recipe steps in the proof of concept, so I have to augment it with the Paprika app on my iPhone. It’s funny, there are quite a few apps out there that are good at organizing recipes, showing cooking steps, and building shopping lists, but none of them do meal planning the way I want it done. All of these apps are basically little silos of data so there isn’t a great way to plugin to them so I can add just the meal planning side. To do meal planning, I have to rebuild everything else (recipes, shopping lists, etc) or the meal plans aren’t usable.

On that front, one of my goals for MealMind is to have an API so you can import/export data easily and other apps can build on top of it. If you just want to use it as a recipe database, it should be able to do that. The only catch with other apps using it is that the existing formats aren’t great for what MealMind needs once we get to some features down the line. That’s a ways off though, so I’m sure there will be lots of additional thought going into that over time.

Making MealMind #7: Still Holding

I’ve got several other projects I’m working on at the moment, so I still haven’t made any new progress on MealMind. I’m still toying around with some things like AWS Lambda as well as working on some totally unrelated projects. I think I’ll make some new progress on MealMind next week, but it depends on how the other projects go.

I have been thinking about the UX for MealMind though. I’m not at the point that I’m doing mockups or building out the “real” UI yet, but I’ve been thinking more about how it should work compared to the proof of concept app I have now. I’m considering taking a month or so to try working through some design books to see if I can up my UI/UX skills a bit, but I don’t know if that will be enough to make a difference. I’d love to have a real designer and UX expert to work with on this, but I think that’s a post-launch (and post-profit) thing. I expect I’ll try to find a decent HTML template that already exists and try to adapt it a bit for the initial version. I definitely like Bootstrap + some customized themes on top. It’s not perfect, but at least it helps to get things off the ground quickly.

We’ll see what happens this week, but hopefully, I’ll have something more interesting to share next week.

Making MealMind #6: Holding Pattern

Not a lot has happened in the MealMind world this past week. I’m still using the proof of concept to prepare my grocery shopping list and it’s still working great. I haven’t made any updates, but I have a little list of items to knock out. I’ve been playing with AWS Lambdas using C# with .NET Core 2.1. It actually works really great, so I’m thinking through whether I want to actually build each API call as a Lambda and then wire up an API Gateway in front of it to make it feel RESTful.

Lambdas aren’t anything magical, but I do like the idea of building very focused little functions. Additionally, for a small developer, it should be possible to host the service very cheaply with lambdas since you only pay for the actual time the code is running. It also makes it easy to automatically scale up individual parts of the app as needed. At the moment, there isn’t really a technical reason to do anything other than a normal ASP.NET API, but in theory, a set of lambdas would be more future proof and wouldn’t cost much. The huge downside is managing the deployment of a suite of lambdas. If I have, say, 50 different lambdas, it would be a bit of a bear to publish all of them vs deploying just a single ASP.NET API website.

At this point, I think I’ll just take a couple of weeks to experiment with a couple of different things while tweaking the proof of concept a bit. I don’t want to be stuck in an analysis phase forever, but I’m learning more and more with my proof of concept so waiting a little longer to build the “real” thing won’t hurt. I also want to make sure I build on a foundation that I won’t regret 6 months from now.