This is a submission for the Hacktoberfest Weekend Challenge: Build for a Friend
What I Built
I built Gastronomical, an AI-powered research and content creation tool for food creators. I built it for my friend, Amasco, who creates food content mainly through carousels.
Her workflow usually starts with a basic idea. Maybe she wants to make a post about chili recipes or desserts without added sugar. She starts with a research of finding recipes, comparing different versions, checking measurements and serving sizes, finding the right images, and eventually turning everything into a carousel. Since she doesn't have a content manager, she has to do all of this herself.
I thought i could solve that by building a better research tool.
My first version was basically a research dashboard. It searched for sources and images and used AI to analyze what it found. Technically, it worked. Then i showed it to my friend, and she told me she wasn't going to read through all of that. That was useful feedback.
She wanted the actual recipes, measurements, serving sizes, useful comparisons, relevant images, and something that could help her get to a finished carousel faster. So i changed the product around her actual workflow.
Now, Gastronomical takes a food idea, finds relevant recipes and sources, extracts the useful information, and turns the research into creator-ready content and a carousel.
The goal is to do less research and more creating.
Demo
The live application is available here: Gastronomical
I also recorded a short demo showing the complete workflow from searching for a food topic to generating a carousel:
The most important part of the demo is the actual creator workflow. I wanted to show that Gastronomical isn't just an AI research interface. The point is to go from a food idea to usable content with as little repetitive work as possible.
Code
There are a few parts of the codebase that I found particularly interesting:
Searching the web with SerpApi
Gastronomical uses SerpApi for Google Search and Google Images. I wanted the application to work with current web information rather than asking an AI model to rely entirely on what it already knows. The search results become the evidence that the rest of the research pipeline works from.
Extracting recipes
When Gastronomical finds a recipe page, it first looks for structured recipe data such as JSON-LD. That gives me access to information such as ingredients, instructions, cooking time, and yield when the website provides it. If that structured data isn't available, the application falls back to extracting useful page content.
One important rule is that Gastronomical does not turn incomplete information into a complete recipe. If a source doesn't provide a measurement, the application doesn't invent one. If a page isn't actually a recipe, it remains a source rather than being presented as one.
Giving the AI structured output
Once the research has been collected, it is passed to Qwen through OpenRouter. Instead of asking the model for one large block of text, i ask it for structured information:
`{
"summary": "...",
"commonIngredients": [],
"differences": [],
"techniques": [],
"observations": []
}`
That makes the output much easier for the application to work with and keeps the AI layer separate from the presentation layer.
How I Built It
The basic architecture looks like this:
The frontend is built with Next.js, React, TypeScript, and Tailwind CSS.
When a creator searches for a food topic, the application sends the request to the research API. SerpApi handles the Google Search and Google Images requests, and the returned pages are normalized into a common structure.
For recipe pages, i prioritize structured recipe data before falling back to page content. This is important because I want the application to preserve what the source actually says rather than having an AI model reconstruct a recipe from a vague snippet.
The collected evidence is then passed to Qwen, an open-weight model accessed through OpenRouter.
The AI is instructed to work only with the supplied sources. It should not invent ingredients, measurements, techniques, or cultural information that aren't supported by the research.
One of the design decisions I made was to keep AI-generated content separate from visual design.
The model generates the information for the carousel, but React controls how the carousel looks. The slides use a fixed 1080 × 1350 format, with the food image covering the slide and the content layered over it.
I then use html-to-image to turn the rendered carousel into downloadable PNGs.
That means i can completely change the visual design without changing the AI generation logic.
Deploying with Render
I deployed Gastronomical with Render so i could test it as an actual production application rather than only running it locally.
The deployed application connects the frontend to the same research and AI workflow, with API credentials kept in environment variables rather than exposed in the client.
Render made it possible to get the application online quickly without spending the hackathon building infrastructure instead of the product.
Monitoring with Sentry
Gastronomical also depends on several external services. A search request can fail, a recipe page can be unavailable, or an AI provider can return an error. I added Sentry so i can see what happens in production when something goes wrong.
That is particularly useful for a product like this because an external service failing shouldn't simply look to the creator like the app doesn't work.
Why Does Open Innovation Matter?
Gastronomical isn't built around the idea that one AI model should know everything about food.
The application retrieves information from the web first, then gives that evidence to an open-weight model to reason over. That separation gives me much more flexibility. I can change the model without rebuilding the rest of the application, and i can control what information the model is allowed to use.
It also makes experimentation possible. If another open model performs better at recipe comparison or content generation, i can test it against the same research pipeline instead of rebuilding the product around a proprietary model.
For this project, open innovation is what makes the AI layer replaceable and gives me control over how the product uses AI.
Prize Categories
Best Use of SerpApi: SerpApi powers the live web and image research used to ground Gastronomical's AI workflow.
Best Use of Render: Render hosts the deployed production application.
Best Use of Sentry Agent Tracing
Try Gastronomical
Building this for my friend reminded me that the person using the product doesn't care how interesting the technology is if it gives them more work.
My first version was built around what i thought was interesting. The second version was built around what she actually needed.
That's my biggest takeaway from building for a friend.
Top comments (0)