iTranslated by AI
In the AI Era, Products Are No Longer 'Fixed Deliverables' but 'Bundles of Possibilities'!? - Building Cookflow
What I built
I created a cooking support app called Cookflow.
By entering your ingredients, constraints, mood, skills, and available tools, the app provides recipe suggestions on the spot. Even after you start cooking, you can ask questions if you run into any trouble.
This is not just a simple recipe search app.
Instead of looking for pre-existing recipes, Cookflow aims to restructure the cooking process itself to fit the user's situation. That is what I am experimenting with in Cookflow.
The underlying philosophy
I wanted to build this app to test a small hypothesis based on the following idea:
AI allows products to shift from being fixed artifacts to becoming bundles of dynamic possibilities that are continuously co-created with users.
Until now, products were mostly things where "the creator determines the final form, and the user utilizes it."
In the case of a recipe app, there are pre-registered recipes, and users search through them. However, with the integration of AI, the nature of the product can change.
The experience returned changes based on user input, the situation, constraints, preferences, and real-time decisions. The product becomes less like a collection of fixed screens or features and closer to a bundle of possibilities that unfolds for each individual user.
With Cookflow, I tested this in the familiar domain of cooking.
Why cooking?
Cooking is a process-oriented activity that involves more "real-time adjustment" than one might think.
- The ingredients in the fridge are different every time.
- The available tools vary.
- Some days you are short on time.
- What you want to eat depends on your mood.
- Discrepancies occur while cooking, such as burning something, the flavor being too bland, or running out of ingredients.
Cooking does not always proceed according to a fixed recipe from start to finish. It is quite a hassle to look up a recipe, realize you don't have enough ingredients, and then head to the store, even when you just want to whip up a quick meal.
In reality, cooking is a series of ongoing decisions based on the ingredients and time you have on hand. I thought this made it a perfect match for AI.
Key features
As an MVP, I implemented the following:
- Input for ingredients, number of people, time, mood, skills, tools, ingredients to avoid, and notes.
- AI generates 3 recipe candidates.
- Display of overview, time, difficulty, ingredients used, and missing ingredients for each candidate.
- Recipe details page displaying ingredients, instructions, substitutions, tips, and precautions.
- Chat functionality to ask questions during cooking.
- Ability to save evaluations and notes after cooking.
- History display of generated and prepared recipes.
I was conscious of not making it just about "generating and stopping there."
In cooking, discrepancies appear once you start preparing. You might be about to burn something, the taste might be off, you run out of an ingredient, or you want to change a step slightly. To handle such situations, I prepared a Cooking Session where you can ask questions.
Technical architecture
The tech stack is simple:
- Ruby on Rails
- Hotwire / Rails views
- SQLite (local MVP)
- OpenAI Ruby SDK
- OpenAI Responses API
- Structured Outputs
- AI responses are validated as JSON and saved.
AI integration is encapsulated in service objects.
AiRecipeGenerator handles recipe generation, while AiCookingAdvisor handles consultation during cooking.
I configured it to use the OpenAI provider for development and production, and a mock provider for testing.
AiRecipeGenerator.new.generate(recipe_request)
I do not save OpenAI's output as-is. I always parse it as JSON and verify that all necessary items are present before saving.
If meat, fish, or eggs are included, I make sure to include food safety warnings. As a cooking app, I did not want to be careless about this.
Reflections on the build
When building an AI app, if it only "generates something using AI," it tends to just become a traditional form-based app with a generate button added on.
What I focused on this time was treating AI not as a "device that provides an answer just once," but as a partner that moves through the process together with the user.
Recipes are not finished content, either.
- Initial ingredient input
- Candidate generation
- Selection
- Consultation during cooking
- Post-completion evaluation
- History
Throughout this flow, the experience gradually takes on meaning tailored to the user.
This structure seems applicable to areas other than cooking.
For example, learning, travel planning, work procedures, writing, or health management. In all these cases, there are times when it is more natural to design as a "process that changes according to the situation" rather than handing over fixed content.
Summary
Cookflow is a small MVP, but the theme I wanted to test was quite significant.
Through AI, products shift from being providers of finished goods to things that continue to change alongside the user.
I implemented this shift in the everyday experience of cooking.
There are still some rough edges. However, as an experiment for considering AI-first product design, it provided plenty of insights. I view this app as an implementation of a concept rather than something to be established as a service immediately.
Products in the AI era become "bundles of possibilities" rather than "fixed artifacts." What do you think?
Discussion