Let's Get Building - $100k App Challenge #6
This past week, I spent a lot of time trying to figure out this IDFA nonsense that I talked about in my previous post so I didn’t spend a ton of time working on Mealfarm. However, I did make some substantial progress on important pieces.
During the beginning of the week, I felt pretty disorganized. I had validated the idea to some extent, incorporated a company, and now I was ready to start building. I didn’t have a concrete vision of what the actual app was going to look like yet. So I just started brain-dumping into a google doc.
I find writing to be a very useful way to think through problems. Something about putting thoughts into a written document helps me think about things logically. If you read the document, it’s just paragraphs of me talking to myself like this:
This part is a little tricky. How many recipes do I let people prep for? I think if there is a bit of transparency as to how much food it is, then I don’t need to say “pick x recipes.” For example, if for every additional recipe you add, a text updates to say “6 meals worth of food” or something. This also affects serving size. Should every meal assume 1 or 2 servings? How can the user increase the serving size to 2 or 4? If you automatically assume food for 5 days, then I can automatically divy up the servings. I.e. you choose 2 dinner/lunch recipes and 1 breakfast, I’ll assume 5 servings of the 1 breakfast and 5 servings of each dinner/lunch recipe. So maybe that is why I would ask how many days do you want to prep for? [5 days, 1 week, 2 days, none]. That makes sense.
By the end of the paragraph, I’ve come to a conclusion. That’s what I’m going to run with. So I basically went through the important aspects of the app and wrote them out.
I also started wireframing the onboarding flow. I find it important to separate out prototyping and designing. Below, I’m prototyping the flow of the app. I don’t care about design yet. If I tried to make each of these views actually look good, it would’ve taken me hours. With my shitty little screens, I can start to visualize how the app will work. You really get a tangible sense of how it flows. I can rearrange these screens whenever I want as well. I typically will do this for new apps or new features in existing apps. Now we’re getting closer and closer to actually writing some code.
Some Changes, Idea Refinement
A couple of notable things didn’t happen this week. I haven’t continued to post on Reddit like I said I was and I haven’t been thinking about my own recipes. I came to the conclusion that the “zero-cooking” aspect has a nice ring to it but may be a bit too specific. I also wouldn’t be able to think of 100 recipes that fit this model.
I’ve refined the idea even further now. So to get specific, users will input their current weight, goal weight, activity level, and other related info. That will be used to generate a calorie and macro goal that should lead to weight loss, similar to MyFitnessPal. Now, based on that calorie goal, the app will recommend to you specific recipes you can make to achieve it. Then, it’ll output a grocery list for you. You go and buy the groceries, cook your meals, and weight loss should happen. There will be an emphasis on simple, quick meals that don’t require a lot of cleaning or prep-time inspired by the great feedback I got on the “zero-cooking” concept.
Finding Content for New Apps
One of the biggest challenges you face when you’re starting a new app is finding content for it. Here, I like leveraging VAs (virtual assistants). You can hire someone for under $10/hour on Upwork to do all kinds of things. For example, when I was building the first version of Caption Expert, I hired a VA to scrape popular captions from across the internet. We looked at Reddit and some other random sites. Take a look here:
With VAs, the world becomes your oyster. You don’t have to worry if a particular data set isn’t in a nice, free API because you can easily build your own. Having that in your back pocket really unlocks a lot of opportunities, especially in the early days.
How Am I Going to Get Recipes?
So as I started thinking about this and researching recipes and recipe APIs—I made a few observations. I quickly realized the way recipes are stored on the internet is a total mess. Ingredients are listed in plain text, every website stores them differently, serving sizes aren’t normalized, some recipes have prep time/cooking times and others don’t. There’s a way to markdown your recipes so Google will show them in recipe-related searches, but this format doesn’t show nutrition information on a per-ingredient basis. In fact, almost no recipes will show you the per-ingredient break down of nutrition. Recipe APIs tend to be expensive and are not something I want to depend on.
Let’s take a step back. The important question is how will I use these recipes? That will dictate how I store them and how I find them. For all of my recipes, I want to be able to:
1) Calculate nutrition on the fly
2) Enable users to substitute ingredients, or flat out remove ingredients, and still have up to date nutrition info
3) Eventually, let users create their own recipes.
So what I need to do is to store every ingredient and its nutrition information. Then, use those stored ingredients as building blocks for recipes. This enables the functionality listed above. It shouldn’t be too complicated.
Next, I don’t have the personal bandwidth to think of 100+ recipes for the app or even a couple dozen. I’m not culinary trained. So I decided I’m going to borrow some recipes from across the internet, and then slightly tweak them to simplify them and make them my own. I can then hand them off to a virtual assistant to input into my database.
My Recipe Dashboard
I’m going to build a dashboard for inputting the recipes into my DB. It needs to be simple enough that a virtual assistant can use it. I spent a few days putting together a dashboard. It’s definitely one of the more complex ones I’ve built.
In the beginning, we’ll need to build up a core list of ingredients. For every recipe, you’ll have to add most foods to the database first, then create the recipe that links together those ingredients. Over time though, once recipes start to have ingredients that overlap, you won’t have to add as many new ingredients each time. Eventually, we’ll have thousands of the most common ingredients added with nutrition info and everything.
The Plan!
So my plan for this week is to finish the dashboard and start collecting recipes. I’d like to get a VA started as soon as possible to start inputting those. Then, I need to research the calorie math needed for weight loss and start figuring out how I’m going to implement the algorithm for choosing meals. Once all that is figured out, I can start building the backend for the app. Let’s get to work!
If you made it this far, send me an email (zach@shakd.io) with the subject “banana” and tell me your favorite part. Oh also, I almost forgot. I recently updated my public dashboard to include my company’s accounting information. It’s kinda hard to explain. Take a look here at my new personal website: zach.so/dashboard
