Data mise en place

I love to cook, particularly Cajun and Creole food (Paul Prudhomme is my favourite chef of all time, look him up if you are not familiar!). My typical workflow for cooking is I find a recipe I want to try, read through it once, and then leave the page open while I cook so I can quickly check ingredient quantities, timings, and steps. I am not actually following the steps per say, but I do like being able to reference the recipe. Gobsmacked started as an attempt to make recipes visually better suited to that kind of quick referencing. It seems to me it is 50/50 whether people like to see recipes in this visual format, or they hate it, and I am okay with that.

Currently, it automatically converts recipes into my take on a tree/graph/tabular style visualization. Eventually, I would like it to become a personal kitchen and recipe management system, but for now I am focused on improving the recipe display itself.

What I love about gobsmacked is that it spans both product and systems work. The site has to feel simple and calm for the user, but behind that there is a fair amount of structure needed to ingest messy recipe pages, normalize them, and preserve enough meaning to render them cleanly.

Recipe ingestion and rendering

One of the main technical problems is just how unstructured recipe pages really are. Piping them into a UI that feels deliberate and consistent across all recipes requires lots more wrangling than one might expect, as well as some fun and inventive data structures. Recipes come in with inconsistent formatting, uneven step structure, and wildly different ingredient conventions, so the ingestion flow has to do quite a bit of cleanup before the display layer can make good decisions.

The current version uses LLM-assisted parsing to turn those pages into structured JSON that the app can render as compact recipe cards. A lot of the work has been in shaping that pipeline so the output is not just technically valid, but actually useful to someone glancing at a screen mid-cook.

On the frontend, I built the card presentation around CSS grid so ingredient groupings, quantities, timings, and steps can be scanned quickly instead of read like a blog post. That visual system is the heart of the product for me. It is where parsing quality, layout decisions, and cooking ergonomics all meet.

Future work

I built the account and persistence layer so recipes can move from one-off experiments into a growing personal collection instead of disappearing as soon as the tab closes. It is here that the aforementioned personal kitchen and recipe management system will be born from.

Appwrite acts as the durable source of truth for the web app, which keeps user data, saved recipes, and parser output in one place. That has been especially helpful while iterating on the product, because changes to recipe structure and user flows tend to ripple through both the ingestion pipeline and the interface at the same time.