From a working reference to a chef-first culinary system
Eight preserved milestones of self-directed product research, from Chef's Bible to The Spicy Noodle v3.5.1.
Live browser version of the current culinary reference and tools project.
A system can become technically capable and practically unusable at the same time. Recognising that in my own work, and removing what I had already built, is the part worth looking at.
Sec. 01
Context and operating scale
Professional kitchens expect people to remember an enormous amount of practical information: ratios, temperatures, methods, substitutions, troubleshooting, food-safety controls, portions, equipment behaviour and local operating knowledge.
It usually exists. It is just scattered across memory, notebooks, recipe apps, spreadsheets, manuals and verbal handover.
The work began with one question: can the knowledge a chef repeatedly needs be made easier to find and use while the work is happening? Each iteration answered it at a deeper level.
Sec. 02
The real problem
Existing tools ask a chef to behave like a database administrator before they can look up a ratio.
The harder problem emerged later, and from my own builds rather than anyone else's: a system can become technically capable and practically unusable at the same time. Cooked weights, edible portions, deep costing links and universal production fields all made sense individually, and together they turned a cooking tool into an accounting one.
The eight milestones below are not eight correct answers. Two of them over-expanded, and correcting that is the part of the sequence worth showing.
Sec. 03
My role
- Defined the product, content, workflows and interface direction throughout
- Built working prototypes using modern development and AI-assisted tools
- Domain modelling and content architecture across the culinary reference
- Interface critique and information architecture
- Scope correction — including removing capability after building it
- Mobile and poor-connection interaction design
Sec. 04
What I designed
Across eight builds a set of product principles hardened into rules.
- Answer first, depth on demand
- Built for mobile and poor connections
- Culinary language rather than accounting language
- Contextual tools rather than universal complexity
- Raw source preserved, so nothing is lost in translation
- Safe scaling with visible uncertainty
- One canonical source for each piece of knowledge
- Complexity belongs underneath the interface, not in front of the chef
- Keep the recipe and working interface light; attach specialised tools only where the culinary context justifies them
Chef's Bible
What must a working chef remember, and how can it be made portable?
A dense professional reference: bread formulae, pastry ratios, sauces, protein temperatures, fish, sugar, chocolate, stocks, curing, allergens, conversions and troubleshooting. An external memory system.
- What it proved
- Ratios, temperatures and rescue guidance beat long-form culinary writing during service. Mobile access mattered from the first build.
- What was still limited
- It stayed long and flat. Navigation meant scrolling. It could display knowledge but could not respond to what the chef was trying to do.
- What it made me ask next
- How should the same knowledge change when the working environment changes?
Galley Bible
How should culinary knowledge behave in a galley rather than a restaurant?
The reference expanded into fish butchery, yacht desserts, provisioning and galley operations. The change was not only more content — it introduced the idea that the environment should shape the knowledge system.
- What it proved
- Provisioning, storage, handover and operating conditions are part of culinary performance. A useful reference has to cover what happens around the cooking.
- What was still limited
- Still fundamentally a long document, and operational content had started competing with culinary content for attention.
- What it made me ask next
- Can the chef enter through the task rather than the document structure?
Fond v1.0
Can search become the front door instead of the table of contents?
A distinct product identity, describing itself as a working kitchen reference rather than a cookbook. Search-first, collapsible, category-filtered and built to work offline. The same build introduced the Flavour Pairing Engine and Pantry Builder, moving the system from 'find a fact' towards 'tell it what you have, and get relevant culinary possibilities back'.
- What it proved
- Progressive disclosure beat showing everything at once. Offline and phone-first operation could be part of the proposition rather than an afterthought. Culinary knowledge could support decisions, not only answer lookups. That is a different product.
- What was still limited
- Capability was growing faster than the structure holding it.
- What it made me ask next
- Can the system help build a dish, not only answer a question?
Fond 1.5
What structure does a system with several genuinely different jobs need?
An application shell around four pillars: Reference, Builder, Calculators and Knowledge. The first serious information-architecture step.
- What it proved
- Focused calculators worked better separated from general reference. Depth could stay available without blocking the quick answer.
- What was still limited
- The categories described the content architecture, not the user's intention. Capability was starting to show up as visible complexity.
- What it made me ask next
- What is the user actually trying to do right now — find, build, learn or calculate?
The Spicy Noodle v2.6
Can beginner explanation and professional reference live in one product?
A new identity and a learning layer: clearer explanations, safety context and culinary reasoning, without losing the fast working answer. The line was 'Find it. Use it. Get back to cooking.'
- What it proved
- One screen could carry a culinary target, a safety baseline and the reasoning for the gap between them. Plain language did not mean dumbing down.
- What was still limited
- The collection of calculators, builders and reference tools was growing without a front door that made sense of it.
- What it made me ask next
- Can this be presented as one coherent suite rather than a pile of features?
v3.3.1
Can specialised culinary tools share one design language?
A front door presenting six capabilities: Dough Calculator, Kitchen Converter, Dish Builder, Protein & Centrepiece Guide, Dressing Builder and Texture Lab. This made the breadth legible for the first time.
- What it proved
- Culinary logic could become purposeful builders rather than generic forms. A curated front door protects the user from the size of the library underneath.
- What was still limited
- This is the version that showed me the real risk. Tools could be added indefinitely, and every useful adjacent idea could become another permanent surface.
- What it made me ask next
- Can the architecture organise around intention instead of accumulating around features?
v3.4.5
Can navigation follow the user's current goal rather than the content's shape?
Four governing workspaces: Find, Build, Learn and Tools. Builders and calculators stayed independent while sharing a platform.
- What it proved
- Search, knowledge and action could be related without being visually mixed. This is where it started to behave like a culinary operating system rather than a very large reference page.
- What was still limited
- The model was right; the execution still needed to get calmer and faster.
- What it made me ask next
- How does the same architecture become steadier on a phone?
v3.5.1
Is the next release another feature family, or the same one done properly?
The four-workspace model held. Access to the Culinary Index, Shelf, Search and Guide became explicit, mobile navigation was strengthened, and the Build workspace got easier to reach.
- What it proved
- Refinement mattered more than another feature family. Ingredients, techniques and preparations began behaving as connected entities. One-hand phone navigation is not a nicety for a product used in a working kitchen.
- What was still limited
- Still no chef other than me has used it under service pressure. That is the gap, and no amount of further design closes it.
- What it made me ask next
- Put it in front of real chefs, in a real kitchen, and watch.
Sec. 05
How it was used
These were built outside the scope of any job, on my own time, to develop the skill. Not commissioned client products and not employer work. They exist and they run; what they have not accumulated is users, and this page does not imply otherwise.
I defined the product, content, workflows and interface direction, and used modern development and AI-assisted tools to build the working prototypes. That is the accurate description of the role — it is product and systems design with working software attached, not a software engineering career.
Every screenshot on this page is an unedited capture of a preserved build. Nothing has been redrawn, and no visible limitation has been tidied away.
Sec. 05b
What the over-expansion taught
Two of these versions got too broad, and the sequence shows it rather than hiding it.
The instinct that caused it is a reasonable one: cooked weights, edible portions, deep costing links and universal production fields are all defensible individually. Together they turn a cooking tool into enterprise kitchen software, and a chef mid-service will not use enterprise kitchen software.
The correction became the governing principle: keep the recipe and working interface light, and attach specialised tools only where the culinary context justifies them. Complexity can live underneath — sophisticated validation, conversion and relationships are fine — as long as it never asks the chef to behave like a costing manager.
Recognising that in my own work, and then removing capability I had already built, is the part of this case study I would want a product team to look at.
Sec. 06
Before and after, side by side
Unedited captures from the preserved builds. The early dense tables are the point: they show the starting problem, and they are what makes the later hierarchy mean anything. Click any capture to see it full size.
Sec. 07
Relevance by outcome
Product capability demonstrated
- Product discovery across eight iterations
- Domain modelling and content architecture
- Information architecture and interface critique
- Mobile UX under poor-connection constraints
- Rapid prototyping with modern and AI-assisted tools
Judgement demonstrated
- Scope correction after expansion
- Willingness to remove capability already built
- A defended boundary between chef tools and management tools
- Preference for one canonical source over duplicated content
Operational relevance
- Knowledge that survives a handover
- Reference usable at the pass, not at a desk
- Offline operation as a design constraint, not a feature
- Training value for less experienced staff
Where it points next
- Yacht and fleet culinary continuity
- Hospitality training and handover
- Recipe-library audits
- Chef-facing product consultation
Sec. 08
Evidence ledger
Each statement on this page sits at one of five levels. Measured means recorded and quantified at the time. Documented means a retained artefact or record exists. First-person account means it rests on Ciarán's own testimony with no external corroboration. Inferred means it is reasoned from the design rather than shown by data. Not claimed means the page is explicitly not asserting it, and says why. Nothing is published above the level its evidence supports.
Eight preserved milestone builds exist and are available for inspection.
The lineage from Chef's Bible through Galley Bible and Fond to The Spicy Noodle v3.5.1.
Features shown in screenshots.
Every image is an unedited capture of a preserved build.
The scope correction after v3.3.1 and the principles that followed it.
That these are self-directed prototypes, not commissioned client products.
User adoption or number of active users.
None. No chef other than me has used these under service pressure.
Commercial results.
None. Deliberately not stated.
Fleet-platform capability.
Researched future application only. Not a current capability.
Independent editorial review of culinary statements and calculations.
The culinary content is Ciarán's own and has not been reviewed by a third party. Calculations are unaudited.
Senior full-stack software engineering.
Not claimed. The role is product, content and interface direction, with prototypes built using modern and AI-assisted tools.
Sec. 09
Reflection and next iteration
The most useful decision across eight builds was subtraction. v3.3.1 gained tools quickly and got harder to use; v3.4.5 exists because I was willing to reorganise around what people were trying to do rather than what I had built.
The architecture holds. The next step is putting a focused version of it in front of chefs in one real kitchen, under service pressure — which is exactly what a custom iteration is for.
Sec. 10