uPrep - Cook different.

TLDR

I've made a batch-cooking app to help users save time by generating simple-to-follow personalized cooking sessions that are tailored to their kitchen and skill level!

Motivation

Like many people, I picked up the habit of cooking regularly to control my diet better. Since I didn't want to cook throughout the week, I've decided to dedicate my Sundays to it, filling 15 containers I'd eat from on weekdays.

I've been doing this for about half a year, and gradually I've grown to HATE it. Since I'm cooking as a means to an end, I'm not particularly there to enjoy the process - instead I have to exert energy and I'm just stressed and annoyed instead. Can you relate?

Naturally over time, I started looking for help - Youtube videos, cooking apps, subreddits - anything to help make my habit more bearable. After some research I've noticed, that the cooking industry online isn't made for people like me. Most stuff I find is to "Get inspired 💅" or to entertain - I can't tell you how many times I've sat down wanting to prepare new recipes for Sunday - but ended up spending hours watching videos on which Tiktok chef dry-ages exotic meats best - all while telling myself this is useful "research".

Even if I find the recipes I want to make - I still have to manually calculate macros, make sure I can even cook the recipes in bulk with my limited equipment, check for volume, freezer friendliness, sum ingredients, etc-etc, you get the idea.. Needless to say, if you want to start to cook in bulk, or introduce new recipes, HOURS get wasted.

So when I set down after my last product thinking of what to make next - The idea naturally came, to disambiguate and optimize cooking as much as possible for disinterested people so they spend less time in the kitchen overall, the the time spent there is less stressful.

Execution

The core idea is this: Recipes are nothing more than poorly written code - What if we could formalize all recipes to follow this format (see example below) - assign abstract requirements for each cooking process that certain equipment can satisfy - and pass selected recipes with portions to a solver, so that each user gets an optimal, CUSTOM cooking session plan, tailored on their kitchen!

In theory, this would save an awful lot of time for an awful lot of people, if I can get it to them in an easy-to-use format, like a modern mobile app with clean UX. Here are the most important things my app does:

Recipe standardization

This is BY FAR the most difficult part. If you search for recipes via. google, they are 90+% clutter. First you are forced to swipe through a 20 page blog post on the author's childhood memories with their grandma or something - after that, there is a half-page dedicated to the actual instructions and ingredients, in an unstructured, raw text format.

For true standardization, beyond removing obvious clutter - recipes need to have shared ingredient and operation (e.g. mix, whisk, bake) pools. Since it's not viable to hand-author recipes by hand I need operations to be "smart", i.e. they need to declare: what ingredients they ACCEPT, what they DO with them, and what equipment they REQUIRE to do so. (e.g. you cannot whisk a steak)

Do this well, and we can give everything to an AI agent - and like building blocks, and they construct validated recipes. Just to give you an idea of the magnitude of this task, here are a few gems of how recipes declare operations:

• “Cook until fragrant”

• “Season to taste”

• “Reduce until the sauce coats the back of a spoon”

• “Cook until done”

• “Melt a knob of butter”

Not to mention the 1000's of edge-cases I had to deal with - e.g. what operations produce isn't deterministic. Boiled egg is hard, boiled potato is soft, etc-etc.. - I think you get the idea.

The result? A normalized database with 41+ TABLES, which will probably still increase, but that is in theory able to handle any recipe/operation/ingredient. My partial normalization probably adds unnecessary complexity, but the DB itself can validate incoming recipes too, and I can see exactly where errors come from.

In this cycle I didn't finish populating the DB. However I sequentially added a couple of recipes to stretch the schema's limits. As an example, you can see a complex recipe of a Marlenka honey cake.

Kitchen modeling

Modeling equipment was surprisingly easy - each equipment has to declare of itself what it can be used for and how (e.g. Over requires no active effort, chopping with a knife does). Of course the user doesn't see any of this, they have access to a predefined default kitchens, but they can fully customize their own, adding any common kitchen equipment they have in their own kitchen.

Cooking session scheduler

This is where it all comes together - the user configures their kitchen and selects which recipes they want to cook - as an input for my scheduler. The scheduler's job is to find the best possible order to perform these operations in the user's kitchen, optimizing for time - maximizing overlap, minimizing "dead time" - but still being realistic.

Cooking at this state is collapsed into an EQUIPMENT-CONSTRAINED SCHEDULING PROBLEM solved for (close to) the time optimum.

To solve this, beyond tracking equipment-occupancy (i.e. "which pot is used when") I've created a full thermal engine tracking energy transfer requirements for heating any substance, including state changes and passive heat loss.

As you can see, the scheduler's current version generates a Gantt-chart of the scheduled tasks, along with showing the user equipment usage. This isn't user-friendly yet enough for release, I will create an easy-to-follow guide, with human-readable steps next.

Takeaways

(Haha, get it? Takeaway.. food.. - I'll see myself out)

Here are my takeaways for my second public, but my hardest ever project - enjoy!

Project ideas you believe in are terrifying

This is the most genuine takeaway I have thus far, and in this project everything ties back to this -

Everyone gets the advice to: "Just try things, and see what sticks". OK, but 99% of your ideas don't make it to the "try phase" and even if one does, chances are you have doubt it, lessening the chance to go to the "stick phase".
But what if you have less (or even no) doubts about the idea? - well you must doubt something, hmm... How about yourself?

Decisions tend to get harder, time spent on anything increases, as you get this thought of "this must be literally perfect" in the back of your mind. I haven't gotten around to solving this, I just got to the notice part.

Failure is inevitable

Not going to lie, I completely failed to keep the 3-week deadline or post schedule at the second project. Due to the above mentioned reasons, the project is massively overscoped - didn't validate in time, spent WAY too much time perfecting every little thing.

Having people around you ask "what's up" tends to help a little in my experience, but decisions don't really get easier, you just cram in more work to complete these mini-deadlines - which will cause burnouts eventually.

Building is AWESOME

This was the most fun I've had working on anything in my life. I've experienced both exhilarating highs and deep lows during this project. Sometimes I felt so good I was dancing in the office singing Le Festin (that one song from Ratatouille) over-and-over, despite not speaking French:)
And sometimes I was threading water for days, not accomplishing anything - feeling anxious about what I'm even doing with myself.

Overall 10/10 would recommend it. Makes you feel ALIVE. Go give building a try, would you?

Until next time - love, Balázs